著者: Keun Soo Yim Author: キューン・ソー・イム Table Of Links 左のテーブル 抽象化 I. INTRODUCTION I.導入 II. BACKGROUND II.裏面 III. DESIGN 3.デザイン 定義 デザイン目標 フレームワーク 拡張 IV. MODELING 4.モデリング クラス ファクター V. DATA COLLECTION V.データ収集 VI. CHARACTERIZATION VI.特徴 脆弱性修正遅延 変化を修正する脆弱性分析 脆弱性誘発変化の分析 VII. RESULT 第7話 結果 NFOLD認証 オンライン展開モードによる評価 VIII. DISCUSSION 第8話 議論 複数のプロジェクトへの影響 Android セキュリティワークの影響 有効性の脅威 代替アプローチ IX. RELATED WORK 9.関連事業 CONCLUSION AND REFERENCES 結論と参照 ABSTRACT 抽象化 この論文は、入力するソースコードの変更に対するセキュリティレビューを選択的に引き起こすフレームワークを紹介しています。 コードレビューサービス内のレビューボットとして機能するため、フレームワークは、コードの変更がソースコードレポジトリに提出される前に事前提出時に追加のセキュリティレビューを自動的に要求することができます。 オンライン分類器は、さまざまな種類の入力機能を活用して、レビューパターンを分析し、ソフトウェアエンジニアリングプロセスを追跡し、特定のコード変更の範囲内で特定のテキストパターンを採掘します。分類器とその機能は、送信されたコードの変更から得られたデータと、Android Open Source Project (AOSP) の脆弱性を報告することにより慎重に選択され、最適化されます。 私たちは、VPフレームワークの複数のプロジェクト設定における展開の影響と、Androidのセキュリティ研究の将来の方向性について議論します。この論文は、コードの変更-granularityの脆弱性予測に対する私たちのアプローチを調査し、検出し、提出前に脆弱なコードの変更を予防的に検出することによって、ソフトウェアのセキュリティのための予防技術を提供します。 I. INTRODUCTION I.導入 モノのインターネットデバイス(スマートフォンやテレビなど)のためのフリー・オープンソースソフトウェア(FOSS)サプライチェーンは、セキュリティ攻撃者(サプライチェーン攻撃など)にとって魅力的な経済的ターゲットを示す(例えば、サプライチェーン攻撃[20][21][28])。 特定の広く使用されているオープンソースプロジェクト(例:OSカーネル、ライブラリ、ブラウザ、またはメディアプレーヤー)をターゲットにすると、これらのプロジェクトは通常、広範囲の消費者製品をサポートしているため、影響を最大化することができます。これらの製品の迅速なソフトウェア更新サイクルは、各ソフトウェア更新またはリリース前に厳格なセキュリティレビューとテストが実施されない場合、上流のFOSSプロジェクトの最新パッチの脆弱性を迅速に取り除くことができます。 全体的な社会的視点から見ると、このような脆弱なコードの変更を事前提出時に早期に識別することで、全体的なセキュリティテストコストを最適化することができ、それらの変更が上流のオープンソースプロジェクトリポジトリに提出される前に。 これらの下流プロジェクトは、合併した上流の脆弱性を特定し、修正するために最初の下流プロジェクトに依存することはできないため、そのような修正とその後の上流のためのタイムフレームは予測不能である(例えば、部分的に内部ポリシー(22)による)。 すべてのコード変更のための包括的なセキュリティレビューを要求するという天真なアプローチは、多くの上流オープンソースプロジェクトオーナーにとって非現実的なコストを引き起こします。 機械学習(ML)分類を用いてコードの変更の脆弱性評価を自動化するフレームワーク。 Vulnerability Prevention (VP) 分類モデルは、特定のコードの変更が少なくとも1つのセキュリティ脆弱性を含むか、または引き起こす可能性を推定します。コードの変更は、平均的な確率・脆弱性の限界を超えるものです。モデルは、関連する分析ツールのセットを使用して生成された歴史データに基づいてトレーニングされています。モデルは、ソフトウェアの欠陥予測に使用される共通の機能と、キャプチャする4種類の新しい機能を使用します: (1)パッチセットの複雑性、 (2)コードレビューパターン、 (3)各ソースコードファイルのソフトウェア開発ライフサイクル段階、および (4)編集されたソースコードラインの分析によって決定されたコード変更の性質. 合計で、この研究は、MLモデルの精度を最適化するために30種類以上の特徴データを使用して6種類の分類器を包括的に検討する。 トレーニングおよびテストデータを生成するために、Androidオープンソースプロジェクト(AOSP)1で発見され修正されたセキュリティバグを活用します。 (1)各ターゲットのセキュリティバグに関連する脆弱性修正の変更を特定し、 (2) 特定された脆弱性修正変更のそれぞれに関連するバックトラック脆弱性誘導の変更(s) すべての識別された脆弱性誘導の変更は、それぞれのセキュリティバグと関連付けられる前に手動で分析され、検証されます。 THE データの最初の年を用いた評価は、その正確性に基づいてランダム・フォースを最も効果的な分類者として特定します。分類器は、トレーニングおよびテストのためのすべての機能を使用する場合に ~60%の脆弱性誘発コードの変更を ~85%の精度で識別します。 N-fold VPフレームワークは、以前の月のデータを毎月リトレーニングするオンラインモデルとして使用されます。およそ6年間の脆弱性データ3に適用された場合、フレームワークは、脆弱性誘導の変更の約80%のリコールと約98%の精度を示し、99.8%のリコールと確率正常変動の98%の精度を示します。 概要として、レビューされたコードと統合されたコードの変更の7.4%が脆弱性誘発的であると分類されています。平均して、コードレビュー中に追加の注意を必要とする可能性のある正常な変更の数は月あたり約7件です。 この研究の主な貢献には、以下が含まれます。 We explore and confirm the possibility of code change-granularity vulnerability prediction that can be used to prevent vulnerabilities by flagging likelyvulnerable code changes at pre-submit time. We present the Vulnerability Prevention (VP) framework that automates online assessment of software vulnerabilities using a machine learning classifier. We devise novel feature types to improve the classifier accuracy and reduces the feature data set by evaluating the precision and recall metrics. We present the specialized tools to label code changes in AOSP, facilitating robust training and testing data collection. We demonstrate a high precision (~98%) and recall (~80%) of the VP framework in identifying vulnerability-inducing changes, showing the potential as a practical tool to reduce security risks. We discuss the implications of deploying the VP framework in multi-project settings. Our analysis data suggests two focus areas for future Android security research: optimizing the Android vulnerability fixing latency and more efforts to prevent vulnerabilities. The rest of this paper is organized as follows. Section II provides the background information. Section III analyzes the design requirements and presents the VP framework design. Section IV details the design of the ML model, including the classifier and features for classifying likelyvulnerable code changes. Section V describes the tools developed to collect vulnerability datasets for model training and testing. Section VI describes the data collection process using the tools, and characterizes the vulnerability issues, vulnerability-fixing changes, and vulnerability-inducing changes in an AOSP sub-project. Section VII presents the evaluation of the VP framework using an N-fold validation. Section VIIII extends the framework for real-time, online classification. Section IX discusses the implications and threats to validity. Section IX reviews the related works before concluding this paper in Section X. II. BACKGROUND II.裏面 このセクションでは、AOSP (Android Open Source Project) をケーススタディとして使用するオープンソースソフトウェアプロジェクトのコードレビューと提出プロセスを概説しています。 コード変更(単に変更)は、ターゲットソースコードリポジトリ(Git)にあるソースコードファイルのソースコードラインの追加、削除、および編集のセットで構成されます。典型的なソフトウェアエンジニアは、送信前に強制的なコードレビューのためにコード変更をコードレビューサービス(Gerrit4)に送信します。 コード変更は、AOSPで関連する電子メールアドレスを持っている著者に割り当てられます。 コード変更 . コード変更 コードレビュープロセス中に、コードの変更は複数のレビューを受けることができ、その結果、1 つまたは複数のパッチセットが発生します。 コードレビューサービスにアップロードされた各パッチセットは、コードの変更の更新バージョンを表します。 指定されたコードレビュー(s)によるさらなるレビューまたは承認のための新しいパッチセットとして、コード変更のライターが変更を修正し、再送信することができます。キーレビュー者権限には、変更がレビュー者に良いように見えることを示す +1 のスコア、コード変更を承認するための +2 のスコア、変更が良いように見えないことを示す -1 のスコア(例えば、マイナーなエピソード)、およびコード変更の提出をブロックするための -2 のスコアが含まれます。 コードレビュー コードレビュー プロジェクト(例えば、 git リポジトリや git リポジトリのサブディレクトリ)には、カスタマイズされた許可およびレビュー ルールがある場合があります。 たとえば、カスタマイズされたレビュー ルールは、作者がコードレビューサービスに非最終的なバージョンをアップロードする場合が多いので、作者がプレビューテストの準備ができているコードの変更をマークできるようにするためです(たとえば、diffs5 と初期のフィードバックをチェックするために)。 この論文は、CC by 4.0 Deed (Attribution 4.0 International) ライセンスの下で archiv で利用できます。 この紙は CC by 4.0 Deed (Attribution 4.0 International) ライセンス available o n arxiv n ファイル
