静的解析とは

静的解析とは

静的分析は、アプリケーションを実行せずにソースコードを自動的に分析することです。

プログラムの実行中に分析が実行される場合、動的分析と呼ばれます。

スタティック解析は次のものを検出するためによく使用されます。

• セキュリティ上の脆弱性。
• パフォーマンスの問題。
• 標準への違反。
• 時代遅れのプログラミング構成体の使用。

静的解析ツールはどのように機能しますか?

すべての静的解析ツールに共通する基本概念は、ソースコードを検索して、何らかの警告や情報が関連付けられている特定のコーディングパターンを特定することです。

これは、「JUnit 5のテストクラスは「公開」である必要はない」というような単純なものかもしれません。あるいは、「信頼できない文字列入力が SQL 実行文で使用されている」など、見分けが難しいものもあります。

静的解析ツールは、この機能の実装方法が異なります。

• 抽象構文木 (AST) を作成するためのソースコード解析技術
• テキスト正規表現マッチング、
• 上記の組み合わせ。

テキストでの正規表現マッチングは非常に柔軟で、一致させるルールを簡単に記述できますが、多くの場合、誤検出が多数発生する可能性があり、マッチングルールは周囲のコードコンテキストを認識しません。

AST 照合では、ソースコードを単なるテキストで埋められたファイルではなく、プログラムコードとして扱います。これにより、より具体的で状況に応じた照合が可能になり、コードに対して報告される誤検出の数を減らすことができます。

継続的インテグレーションにおける静的解析

多くの場合、静的分析は継続的インテグレーション（CI）プロセス中に実行され、コンプライアンス問題のレポートを生成します。このレポートをレビューすると、時間の経過とともにコードベースを客観的に把握できます。

コードの特定の部分のみを測定し、ルールのサブセットのみを報告するように静的分析ツールを構成することで、コード品質の客観的な尺度として静的分析を使用する人もいます。

客観性は、使用されるルールによって決まります。これらのルールは、時間の経過とともにコードの評価において変化しないためです。明らかに、使用されるルールの組み合わせとその構成は主観的な決定であり、異なるチームは異なるタイミングで異なるルールを使用することを選択しています。

CI で静的解析を実行することは便利ですが、プログラマーへのフィードバックが遅れる可能性があります。プログラマーはコーディング時にフィードバックを受け取らず、後で静的解析ツールでコードを実行したときにフィードバックを受け取ります。CI で静的解析を実行することによるもう 1 つの副作用は、結果を無視しやすくなることです。

チームが Static Analysis の結果に注目しやすくするために、通常、ビルドプロセスでしきい値メトリクスを設定して、メトリクスを超えた場合にビルドが失敗するように設定できます。たとえば、多数のルールがトリガーされた場合などです。

IDE での静的解析

フィードバックをより早く受け取るために、IDE の静的分析ルールをオンデマンドで、またはコードが変更されたときに定期的に実行する IDE プラグインが多数用意されています。

プログラマがコードを記述しているときに IDE でルール違反を確認できるようになり、ルールを無視しにくくするために、エディタで下線付きのコードとしてレンダリングするように違反を設定できることがよくあります。

個人的には、これはコーディングを改善するのに便利な方法だと思います。特に、Static Analysis ツールでカバーされている新しいライブラリを使用する場合は特にそうです。ただし、誤検出や興味のないルールがあると「ノイズが多い」場合があります。しかし、特定のルールを無視するように静的解析ツールを設定するという追加の手順を踏むことで、この問題を解決できます。

静的分析ルールに基づくコードの修正

ほとんどの静的解析ツールでは、ルールの修正はプログラマーに任されているため、プログラマーはルール違反の原因と修正方法を理解する必要があります。

違反を修正する機能を備えた静的分析ツールはほとんどありません。修正は、多くの場合、チーム、使用するテクノロジー、および合意されたコーディングスタイルに合わせて行われるためです。

デフォルトルール

Static Analysis ツールにデフォルトのルールが用意されていると、ルールの品質に対する誤った信頼が生じる可能性があります。プログラマーが遭遇する可能性のあるすべての問題と、そのルールが適用すべきすべての状況をカバーしていると信じたくなります。ルールを適用すべき状況は微妙で、簡単に見分けることができない場合があります。

静的分析ツールを使用し、ルールと違反をより詳細に調査することで、プログラマーが特定のドメインのコンテキストで問題を検出して回避するスキルを身に付けることが期待されます。

ドメインにコンテキストルールが必要な場合、Static Analysis ツールにはドメインまたはライブラリに一致するルールがない場合があり、さらに、ツールの構成や拡張が難しい場合があります。

煩わしさ

これらの「煩わしさ」はどれも乗り越えられないものではありません。

• 偽陽性
• 修正の欠如
• ルールを無視する設定
• コンテキスト固有の規則の追加

しかし、そもそも静的解析ツールの使用を避けるための言い訳としてよく使われます。静的解析は次のような方法として非常に役立つ場合があるため、残念です。

• 若手開発者へのより良いアプローチを強調
• 明確なコーディング違反に関するフィードバックを迅速に取得
• プログラマーがこれまでに遭遇したことのない不明瞭な問題を特定する
• プログラマーが優れたコーディング手法を採用していることを強調する (違反が報告されていない場合)

IDE ベースの静的解析ツール

プロジェクトへの個人寄稿者として、コードに関するフィードバックを迅速に受け取ることができるように、IDE 内から実行される静的分析ツールを使用するのが好きです。

これにより、プルリクエストレビュープロセスや、プロジェクトが持つ可能性のあるCI統合が補完されます。

私は、自分に優位性を与え、個々のワークフローを改善してくれるツールを見つけるようにしています。

ツールを IDE で実行する場合、基本的な GUI と構成アプローチは同じである傾向があるため、同じように表示したくなることがあります。

ツールには重複する機能やルールセットがある場合がありますが、その利点を最大限に活用するために複数のツールをインストールしています。

コーディング時に私が積極的に使用している静的解析IDEツールは以下のとおりです。

• 組み込みの IntelliJ インスペクション-一般的なコーディングパターン
• スポットバグ-よくあるエラー
• SonarLint-一般的な使用パターン
• チェックスタイル-一般的なスタイルパターン
• セキュア・コード・ウォリアーの先生-カスタムルール作成

私はそれらをすべて使用しています。なぜなら、それらは互いに補完し合ってうまく連携するからです。

IntelliJ インスペクション

IntelliJを使用している場合は、すでにそのインスペクションを使用していることになります。

これらは IDE でフラグが付けられた静的分析ルールです。その中には、問題に対処するためにコードを書き換える QuickFix オプションがあるものもあります。

ルールはオンとオフを設定でき、IDE で強調表示するエラーレベルも選択できます。

IntelliJの優れたインスペクションはたくさんあります。私はこれを書いている間にそれらに目を通したので、それを知っています。私は IntelliJ インスペクションをデフォルトとして使用していますが、まだ設定していませんが、インスペクションを最大限に活用するには、インスペクションに目を通し、自分のコーディングスタイルに関連するインスペクションを特定し、コード内で気付くように警告レベルを設定する必要があります。

IntelliJのインスペクションの素晴らしいところは、IDEに無料で付属していることと、次のような筋肉の記憶を構築するのに役立つことです。

• コードを書いているときにソース内の警告やエラーに気づく
• フラグの付いたコードにカーソルを合わせると、ルール違反がわかります
• Alt+Enter キーを使用して問題のクイックフィックスを適用する

スポットバグ

ザの スポットバグ IntelliJプラグインは、静的解析を使用してコードのバグを警告します。

SpotBugs は IntelliJ 環境設定からコードをスキャンするように設定できます。実際に使用されるルールは Detector タブにあります。

私はコードを書いてレビューした後にSpotBugsを使う傾向があり、その後「テストソースを含むプロジェクトファイルの分析」を実行します。

これは、バグ、デッドコード、明らかな最適化を特定するのに役立ちます。また、何をすべきかを判断するために、フラグが立てられた違反のいくつかを調査する必要もあります。

SpotBugs は問題を検出しますが、問題を解決するためのクイックフィックスアクションは提供しません。

SpotBugs は設定が簡単で、IDE で参考にする客観的なセカンドオピニオンとして役に立つと思います。

ソナーリント

ザの ソナーリント プラグイン。

SonarLintは、IntelliJの環境設定から設定して、コードの検証対象となるルールを選択できます。

デフォルトでは、SonarLint はリアルタイムで実行され、編集中の現在のコードの問題を表示します。

SonarLintは迅速な解決策を提供していませんが、違反報告に関連する文書は通常明確で十分に文書化されています。

SonarLint は、これまで Java の新しいバージョンで認識していた新しい Java 機能について警告してくれるので便利でした。

チェックスタイル

ザの チェックスタイル プラグインは、フォーマットとコード品質ルールを組み合わせて提供しています。

CheckStyleプラグインには、「サンチェック」と「Googleチェック」がバンドルされています。

これらの定義は簡単にできます オンラインで見つかりました。

CheckStyleは、プロジェクトが時間をかけて独自のルールセットを作成した場合に最大の価値をもたらします。そうすれば、IDE プラグインがそのルールセットを使用するように設定でき、プログラマーはコードを CI にコミットする前にスキャンを実行できます。

CheckStyle は、CheckStyle 違反の数がしきい値を超えた場合に CI プロセスのビルド失敗プラグインとしてよく使用されます。

先生

先生 コードの照合とクイックフィックスの作成に抽象構文木 (AST) に基づく静的解析を使用します。これにより、問題のあるコードを非常に具体的に特定できます。

ASTを使用すると、レシピに関連するQuickFixが周囲のコードを理解できます。たとえば、コードに新しいクラスを追加する場合、そのクラスのインポートはソースファイルに一度だけ追加され、置換のたびに追加されることはありません。

Senseiは、他のツールには存在しない場合や設定が難しいカスタムマッチングルールを簡単に構築できるようにするために作成されました。

設定ファイルを修正する代わりに、すべての設定を GUI で実行できます。新しいレシピを作成する場合、GUI ではレシピがどのコードと一致するかを簡単に確認できます。また、QuickFixを定義すると、コードの前と後の状態をすぐに比較できます。これにより、チームやテクノロジー、さらには個々のプログラマーに固有のレシピなど、非常にコンテクストに即したレシピを簡単に作成できます。

私はSenseiを他の静的解析ツールと組み合わせて使用しています。たとえば、ほとんどの静的解析ツールは問題を検出しますが、修正はしません。Senseiの一般的な使用例は、他のツールの一致検索をSenseiで複製し、クイックフィックスで拡張することです。これには、適用されたカスタムフィックスがプロジェクトのコーディング標準をすでに満たしているという利点があります。

Intensionレポートが作成したコンテキストと完全に一致しないか、IntelliJが提供するQuickFixが使用したいコードパターンと一致しないことが原因で、IntelliJのIntensionsセットにすでに存在するSenseiレシピを定期的に作成しています。

既存のツールを完全に置き換えようとするのではなく、既存のツールを補強します。

Senseiは、共通ルールのコンテキストバリアントを特定する場合にも非常に役立ちます。たとえば、Static AnalysisツールでサポートされていないSQLライブラリを使用しているが、Static Analysisエンジンの共通SQLルールが引き続き適用される場合は、Senseiを使用してそれらのルールのライブラリ固有のバリアントを作成できます。

Senseiは、前述の静的分析ツールのように一般的なレシピをすぐに提供しているわけではありません。その強みは、特定のコーディングスタイルやユースケースに合わせて構成されたQuickFixを使用して、新しいレシピを簡単に作成できることです。

注:現在、一般的なユースケースに対応するために、レシピの公開リポジトリを作成中です。 ここで見つけることができます。

サマリー

私は、連携して動作し、設定可能で、特定のコンテキストに合わせて簡単に拡張できるツールを選ぶ傾向があります。問題を特定したり、使用しているプログラミング言語やライブラリについて理解を深めたりするために、IDE の静的解析ツールを長年使用してきました。

上記のすべてのツールを組み合わせて使用します。

• IntelliJ Intentionsは、よくあるコードの問題をすぐに報告するのに役立ちます。多くの場合、関連するクイックフィックスを使います。
• SpotBugs は見逃したかもしれない単純なバグを見つけて、パフォーマンスの問題を知らせてくれます。
• SonarLint は、私が気付いていなかった Java の機能を特定し、コードをモデル化する他の方法を教えてくれます。
• CheckStyleは、CI中にも適用される合意されたコーディングスタイルに準拠するのに役立ちます。
• Senseiは、静的分析ツールで見られる一般的なシナリオを補強したり、別のツールでは構成が難しい特定のプロジェクトやテクノロジーレシピを作成したりするためのクイックフィックスの作成を手伝ってくれます。

---

「環境設定\ プラグイン」(Mac) または「設定\ プラグイン」(Windows) を使用してIntelliJ内からSenseiをインストールし、「senseiセキュアコード」を検索してください。

一般的なユースケースのサンプルコードとレシピのリポジトリは、Secure Code Warrior GitHub アカウントの「sensei-blog-examples」プロジェクトにあります。

https://github.com/securecodewarrior/sensei-blog-examples

先生についてもっと知る