# 静的解析の開発者ワークフロー統合 ## 定義 静的解析(static analysis)は、プログラムを実行せずソースコードを解析してバグを発見する技法である。プログラムの任意の性質を静的に検証することは決定不能問題(undecidable problem)であるため、あらゆる静的解析ツールは深さ対解析コスト、偽陽性(誤った警告)対偽陰性(見逃した警告)というトレードオフを本質的に抱える。本 concept が扱うのは、この不可避なトレードオフを**どの開発ワークフロー段階に統合するかによって使い分ける**という設計判断そのものである。統合点が変われば、許容できる解析速度・要求される警告の精度・開発者が受け入れる誤検知率が変わる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 13 Testing Code]] ch.13 §Static Program Analysis) 3層構造として整理できる。(1) **自動コード検査ツール(linter)**: AST パターンマッチによる浅く高速な解析で、コンパイルとほぼ同時間で終わるため対話的な IDE やコミット前チェックに向く。Error Prone(Java)・Clang-Tidy(C/C++)・GoVet(Go)・Pylint(Python)が例で、修正候補を自動提示できるものもある。(2) **コードレビュー統合(Tricorder)**: Google の [[Tricorder]] は1日約5万件のレビュー変更に対して146個の解析ツールを実行し、ユーザー知覚の偽陽性率10%以下を目標にコードレビュー画面へ警告を差し込む。レビュアーの「Not useful」フィードバックでチェックを無効化する自己修正ループを持つ。(3) **抽象解釈(abstract interpretation)ベースの深い解析**: 制御フローグラフに基づきプロシージャ間のデータフロー・制御フローを推論するため実行時間が長く、対話的統合には向かず夜間バッチや差分解析(変更部分のみ解析)で運用される。Frama-C・Infer・AbsInt・Android の App Security Improvement(ASI)プログラムが例。安全重要ソフトウェア(航空機制御等)の最終リリース解析ではさらに厳格な形式手法が要求されることもある。(Source: ch.13 §Automated Code Inspection Tools, §Integration of Static Analysis in the Developer Workflow, §Abstract Interpretation) ## Tricorder の経験則: 採用率を決めるのは精度と修正しやすさ Tricorder の運用から得られた最大の教訓は、静的解析ツールの**採用率**が理論的な検出力ではなく、(1) 警告が理解しやすいこと、(2) 修正しやすい(理想的にはワンクリックで適用できる修正候補が付くこと)、(3) ユーザー知覚の偽陽性率が低いこと、の3条件で決まるという点である。Error Prone・Clang-Tidy が提示する自動修正候補(例: `absl-string-find-startsWith` を `absl::StartsWith` に置換)は、開発者がレビュー画面上でプレビューし即座に適用できる形で提供される。これは、静的解析ツールの価値を「バグを見つける能力」だけで測ることの不十分さを示す——見つけても直されない・無視される警告は、コードレビューという限られた注意資源の中では負債になりうる。(Source: ch.13 §Integration of Static Analysis in the Developer Workflow) ## 横断的知見 - (このconceptは現時点で `Building Secure and Reliable Systems` 第13章のみを情報源とする。複数ソースを突き合わせた横断的知見は今後の ingest で蓄積する。) ## 未解決の問い - Tricorder のユーザー知覚偽陽性率10%という閾値はどのように決まったのか、また解析ツールごとに閾値を変える運用があるのかは本章に記載がない。 - 抽象解釈ベースの深い解析(Infer・Frama-C 等)を対話的な開発者ワークフローに近づける(例えば差分解析の粒度をさらに細かくする)試みは、本章執筆時点(2020年)以降どこまで進んだか。 - [[形式手法]]・[[モジュラー検証]] は「完全な検証はスケールしない」という診断のもとで性質を分解し専用技術を割り当てる設計に至っている。静的解析の3層構造(linter/コードレビュー統合/抽象解釈)は同じ設計原理の別の現れと見なせるか、それとも異なる分解軸(検証の完全性でなく統合タイミング)に基づく独立の設計判断か。 - App Security Improvement(ASI)の「100万件超のアプリ修正」という成果は、Tricorder が重視する「低偽陽性率・修正しやすさ」の原則とどこまで整合しているか、ASI 固有の運用データは本章に記載がなく未確認。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 13 Testing Code]] - 実体: [[Tricorder]] - 概念: [[形式手法]](完全な検証のスケーラビリティという上位の問題意識を共有)/ [[モジュラー検証]] / [[軽量形式手法]](「性質を分解し専用の検証技術を割り当てる」という設計原理との接続は未検討) ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 13.