
静的解析とは何か?
静的解析とは何か?
静的解析とは、アプリケーションを実行せずにソースコードを自動解析することである。
プログラムの実行中に分析が行われる場合、それは動的解析と呼ばれます。
静的解析は、以下のことを特定するために頻繁に使用されます:
- セキュリティ上の脆弱性。
- 性能問題。
- 規格不適合
- 古いプログラミング構文の使用
静的解析ツールはどのように機能しますか?
静的解析ツールに共通する基本的な概念は、ソースコードを走査して特定のコーディングパターンを識別し、それらに警告や情報を関連付けることである。
これは「JUnit 5のテストクラスは必ずしも'public'である必要はない」という単純なものから、「SQL実行文で使用される信頼できない文字列入力」のように特定が複雑なものまで様々です。
静的解析ツールは、この機能を実装する方法において異なる。
- 抽象構文木(AST)を生成するためのソースコード解析技術
- 正規表現によるテキスト比較
- 上記に挙げたものの組み合わせ。
正規表現によるテキストの照合は非常に柔軟で、照合ルールを容易に記述できますが、多くの誤検知を引き起こすことが多く、照合ルールは周囲のコードコンテキストを認識しません。
ASTマッチングはソースコードを単なるテキストファイルではなくプログラムコードとして扱います。これにより、より具体的かつ文脈に応じた照合が可能となり、コードに対して報告される誤検知の数を削減できます。
継続的インテグレーションにおける静的解析
静的解析は、継続的インテグレーション(CI)プロセス中に頻繁に実行され、コンプライアンス問題に関するレポートを生成します。このレポートを確認することで、コードベースの経時的な客観的な概要を把握できます。
一部のユーザーは、静的解析ツールを特定のコード部分のみを測定し、規則のサブセットについてのみ報告するように設定することで、静的解析をコード品質の客観的な尺度として使用しています。
客観性は使用されるルールによって保証される。なぜなら、それらはコードの評価において時間の経過とともに変化しないからである。使用されるルールの組み合わせとその設定が主観的な判断であることは明らかであり、異なるチームは異なる時期に異なるルールを使用することを選択する。
CIで静的解析を実行することは有用だが、プログラマーへのフィードバックが遅れる可能性がある。プログラマーはコーディング中にフィードバックを受け取らず、後でコードが静的解析ツールを通過した際に初めてフィードバックを得る。さらに、CIで静的解析を実行する副次的な効果として、結果を無視しやすくなるという点が挙げられる。
チームに静的解析の結果にもっと注意を払わせるためには、通常、ビルドプロセスでしきい値メトリクスを設定することが可能です。これにより、メトリクス(例えば、トリガーされたルールの数)が超過した場合にビルドが失敗します。
静的解析をIDEで
より迅速なフィードバックを得るために、多くのIDEプラグインが用意されています。これらは、コード変更時に必要に応じて、あるいは定期的に、静的解析ルールをIDE内で実行します。
規則違反は、プログラマーがコードを記述している間、IDE上で表示されることがあります。規則の無視を困難にするため、違反箇所はエディタ内で下線付きのコードとして表示されるよう設定できる場合が多いです。
個人的には、特に静的解析ツールがカバーする新しいライブラリを扱う際に、コーディングを改善する有用な方法だと考えています。ただし、誤検知や関心のないルールに関しては「うるさい」場合があります。しかし、特定のルールを無視するよう静的解析ツールを設定する追加の手順を踏むことで、この問題は解決されます。
静的解析ルールに基づくコードの修正
静的解析ツールの大半では、ルールの修正はプログラマーに委ねられるため、プログラマーはルール違反の原因を理解し、修正方法を知っている必要がある。
静的解析ツールのうち、違反を修正する機能を提供するものはごくわずかです。修正は多くの場合、チーム、使用されている技術、および合意されたコーディングスタイルに依存するためです。
標準規則
静的解析ツールが標準ルールで構成されている場合、ルールの品質に対する誤った信頼が生じることがあります。プログラマーが遭遇する可能性のある全ての問題や、ルールが適用されるべきあらゆる状況を網羅していると信じたくなるものです。ルールが適用されるべき状況は時に微妙であり、容易に認識できない場合もあります。
プログラマーが静的解析ツールを使用し、規則と違反をより詳細に調査することで、自身の専門領域における文脈で問題を認識し回避する能力を身につけることが期待される。
ドメインにコンテキストルールが必要な場合、静的解析ツールにはドメインやライブラリに対応するルールが存在しない可能性があり、さらにこれらのツールは設定や拡張が困難な場合が多い。
厄介事
これらの「厄介事」はどれも克服できないものではない:
- 偽陽性
- 修正不足
- ルールを無視するための設定
- コンテキスト固有のルールの追加
しかし、これらは静的解析ツールの使用を最初から避けるための言い訳として頻繁に用いられており、非常に残念なことである。なぜなら、静的解析の利用は以下のような点で極めて有用となり得るからだ:
- 若手開発者向けの優れたアプローチを強調する
- 明確なコーディング違反について迅速なフィードバックを受け取れます
- プログラマーがこれまで遭遇したことのない難解な問題を特定する
- プログラマーが適切なコーディング手法を選択したことを確認する(違反が報告されない限り)
IDEベースの静的解析ツール
プロジェクトの単独参加者として、私はIDE内で実行される静的解析ツールを好んで使用し、コードに対する迅速なフィードバックを得ています。
これは、プロジェクトが持つ可能性のあるプルリクエストレビュープロセスとCI統合を補完します。
私は、自分に優位性をもたらし、個々の作業フローを改善するツールを見つけようとしています。
IDE内でツールが実行されると、それらは通常同じ基本的なGUIと設定アプローチを使用するため、それらを同義と見なしたくなるかもしれません。
ツールには重複する機能やルールセットがあるかもしれませんが、最大限の利点を得るために、複数のツールをインストールしてそれぞれの強みを活用します。
コーディング時に積極的に使用している静的解析用IDEツールは以下の通りです:
- 組み込みのIntelliJインスペクション — 一般的なコーディングパターン
- SpotBugs — よくあるエラー
- SonarLint — 一般的な使用パターン
- CheckStyle - 一般的なスタイルパターン
- Secure Code Warrior Sensei Secure Code Warrior カスタムルールの作成
私はそれらすべてを使用しています。なぜなら、それらは互いに補い合い、補完し合うためにうまく連携するからです。
IntelliJインスペクション
IntelliJを使用している場合、すでにそのインスペクションを利用しています。
これらはIDEでマークされる静的解析のルールです。一部のルールには、問題を修正するためにコードを書き換えることができるクイックフィックスオプションも備わっています。
ルールは有効化および無効化が可能であり、IDE内で強調表示されるエラーレベルを選択できます。

優れたIntelliJインスペクションは数多く存在します。私がこれを書いている間にそれらをすべて確認したので、そのことは承知しています。私はデフォルト設定のままIntelliJインスペクションを使用しており、特に設定を変更していませんが、インスペクションの効果を最大限に活用するには、それらを精査し、自身のコーディングスタイルに関連するものを特定し、警告レベルをコード内で確実に気づけるように設定すべきです。
IntelliJのインスペクションの素晴らしい点は、IDEに無料で含まれており、以下の「筋肉記憶」を構築するのに役立つことです:
- ソースコードを記述中に警告とエラーを検出する
- マークされたコードの上にマウスカーソルを移動すると、ルール違反を確認できます
- Alt+Enter キーを押して、問題に対するクイックフィックスを適用してください

バグを検出する
バグの検出IntelliJプラグインは静的解析を使用して、コード内のエラーを通知します。
SpotBugsはIntelliJの設定で、コードをスキャンするように構成できます。実際に使用されるルールは「検出器」タブで確認できます。

私はコードを書き終えて確認した後、SpotBugsを使用する傾向があります。その後、「テストソースを含むプロジェクトファイルを解析する」オプションを実行します。

これにより、エラーやデッドコード、明らかな最適化箇所を特定できます。また、報告された違反事項を調査するよう促され、対応策の判断に役立ちます。
SpotBugsは問題を検出しますが、問題を解決しようとするクイックフィックス操作は提供しません。
SpotBugsは設定が簡単で、IDE内で得られる有用な客観的なセカンドオピニオンだと考えています。
ソナー・リント
Sonar Lintプラグイン。
SonarLintは、IntelliJの設定で、コードの検証に使用するルールを選択するために構成できます。

デフォルトでは、SonarLintはリアルタイムで実行され、現在編集中のコードの問題を表示します。
SonarLintは即効性のある解決策を提供しませんが、違反レポートに付随するドキュメントは通常、明確でよく文書化されています。
私はこれまで、SonarLintが新しいJava機能について知らせてくれるのに有用だと感じてきました。それらは、私が新しいバージョンのJavaで知っていたものです。
まだ確認中
スタイルチェックこのプラグインは、書式設定ルールとコード品質ルールの組み合わせを提供します。
CheckStyleプラグインは「Sun Checks」および「Google Checks」とセットで提供されます。
CheckStyleは、プロジェクトが独自のルールセットを作成する時間を費やした場合に最大の価値を提供します。その後、IDEプラグインをそのルールセットを使用するように設定でき、プログラマーはコードをCIに送信する前にスキャンを実行できます。
CheckStyleは、CheckStyle違反の数が閾値を超えた場合に、CIプロセス向けのビルド失敗プラグインとして非常に頻繁に使用されます。
Sensei
Sensei 静的解析を実行し、抽象構文木(AST)に基づいてコードを照合し、クイックフィックスを生成します。これにより、問題のあるコードを非常に特定的に識別することが可能になります。
ASTにより、レシピに関連付けられたクイックフィックスは周囲のコードを理解できます。例えば、コードに新しいクラスが追加された場合、そのクラスのインポートはソースファイルに1回だけ追加され、置換ごとに追加されることはありません。
Sensei 、他のツールでは存在しない、あるいは設定が難しい可能性のあるカスタムマッチングルールを簡単に作成できるようにSensei 。
設定ファイルを変更する代わりに、GUIで設定全体を操作できます。 新規レシピ作成時には、GUI上でそのレシピがどのコードに適用されるかを容易に把握できます。またQuickFixes定義時には、コードの修正前後の状態を即座に比較可能です。これにより、チームや技術、さらには個々のプログラマーに特化した、文脈に即したレシピの作成が容易になります。

Sensei 静的Sensei 。例えば、ほとんどの静的解析ツールは問題を検出しますが、修正は行いません。Sensei 一般的な使用例Sensei 、他のツールの適切な検索をSensei 、クイックフィックスで拡張Sensei 。これにより、適用されるカスタム修正がプロジェクトのコーディング基準に既に準拠しているという利点があります。
Senseiを作成しています。これらは既にIntelliJのIntentionsセットに含まれているものですが、Intentionsレポートが私が作成したコンテキストに完全には合致しない場合や、IntelliJが提供するQuickFixが私が使用したいコードパターンに合わない場合のためです。
既存のツールを完全に置き換えるのではなく、それらを補完します。
Sensei 、一般的なルールの文脈に応じたバリエーションを特定する場合にも非常にSensei 。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジン内の一般的なSQLルールは引き続き適用されます。Sensei 、これらのSensei バリエーションを作成できます。
Sensei 、前述の静的解析ツールのような汎用的なレシピを多くSensei 。その強みは、特定のコーディングスタイルやユースケースに合わせて設定されたクイックフィックスを含む、新しいレシピの作成を容易にする点にあります。
注記:汎用的なユースケースをカバーするレシピの公開アーカイブを現在作成中です。 こちらで確認できます。
要約
私は、連携し、設定可能で、特定の状況に合わせて拡張しやすいツールを選ぶ傾向があります。長年、IDE内の静的解析ツールを使用して問題を特定し、使用しているプログラミング言語やライブラリについて学んできました。
私は上記のツールをすべて組み合わせて使用しています:
- IntelliJ Intentionsは、頻繁に発生するコードの問題を即座に認識し、多くの場合関連するクイックフィックスを提供します。
- SpotBugsは、私が見落としていたかもしれない単純なエラーを見つけ、パフォーマンスの問題について警告してくれます。
- SonarLintは、私が知らなかったJavaの機能を見つけ出し、コードをさらにモデル化するように促します。
- CheckStyleは、合意されたコーディングスタイルを遵守するのに役立ち、CIプロセス中にもそのスタイルが適用されるようにします。
- Sensei 、静的解析ツールで検出される一般的なシナリオを拡張するためのクイックフィックスの作成をSensei 、他のツールでは設定が困難な特定のプロジェクトや技術に関するレシピを作成します。
---
IntelliJSensei をインストールするには、「Preferences\ Plugins」(Mac)または「Settings\ Plugins」(Windows)を開き、「Sensei Code」を検索してください。
Secure Code Warrior のGitHubアカウントにある`sensei`Secure Code Warrior 、一般的なユースケース向けのサンプルコードとレシピのリポジトリをご覧いただけます。
https://github.com/securecodewarrior/sensei-blog-examples
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。

Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
デモを予約するアラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
静的解析とは何か?
静的解析とは、アプリケーションを実行せずにソースコードを自動解析することである。
プログラムの実行中に分析が行われる場合、それは動的解析と呼ばれます。
静的解析は、以下のことを特定するために頻繁に使用されます:
- セキュリティ上の脆弱性。
- 性能問題。
- 規格不適合
- 古いプログラミング構文の使用
静的解析ツールはどのように機能しますか?
静的解析ツールに共通する基本的な概念は、ソースコードを走査して特定のコーディングパターンを識別し、それらに警告や情報を関連付けることである。
これは「JUnit 5のテストクラスは必ずしも'public'である必要はない」という単純なものから、「SQL実行文で使用される信頼できない文字列入力」のように特定が複雑なものまで様々です。
静的解析ツールは、この機能を実装する方法において異なる。
- 抽象構文木(AST)を生成するためのソースコード解析技術
- 正規表現によるテキスト比較
- 上記に挙げたものの組み合わせ。
正規表現によるテキストの照合は非常に柔軟で、照合ルールを容易に記述できますが、多くの誤検知を引き起こすことが多く、照合ルールは周囲のコードコンテキストを認識しません。
ASTマッチングはソースコードを単なるテキストファイルではなくプログラムコードとして扱います。これにより、より具体的かつ文脈に応じた照合が可能となり、コードに対して報告される誤検知の数を削減できます。
継続的インテグレーションにおける静的解析
静的解析は、継続的インテグレーション(CI)プロセス中に頻繁に実行され、コンプライアンス問題に関するレポートを生成します。このレポートを確認することで、コードベースの経時的な客観的な概要を把握できます。
一部のユーザーは、静的解析ツールを特定のコード部分のみを測定し、規則のサブセットについてのみ報告するように設定することで、静的解析をコード品質の客観的な尺度として使用しています。
客観性は使用されるルールによって保証される。なぜなら、それらはコードの評価において時間の経過とともに変化しないからである。使用されるルールの組み合わせとその設定が主観的な判断であることは明らかであり、異なるチームは異なる時期に異なるルールを使用することを選択する。
CIで静的解析を実行することは有用だが、プログラマーへのフィードバックが遅れる可能性がある。プログラマーはコーディング中にフィードバックを受け取らず、後でコードが静的解析ツールを通過した際に初めてフィードバックを得る。さらに、CIで静的解析を実行する副次的な効果として、結果を無視しやすくなるという点が挙げられる。
チームに静的解析の結果にもっと注意を払わせるためには、通常、ビルドプロセスでしきい値メトリクスを設定することが可能です。これにより、メトリクス(例えば、トリガーされたルールの数)が超過した場合にビルドが失敗します。
静的解析をIDEで
より迅速なフィードバックを得るために、多くのIDEプラグインが用意されています。これらは、コード変更時に必要に応じて、あるいは定期的に、静的解析ルールをIDE内で実行します。
規則違反は、プログラマーがコードを記述している間、IDE上で表示されることがあります。規則の無視を困難にするため、違反箇所はエディタ内で下線付きのコードとして表示されるよう設定できる場合が多いです。
個人的には、特に静的解析ツールがカバーする新しいライブラリを扱う際に、コーディングを改善する有用な方法だと考えています。ただし、誤検知や関心のないルールに関しては「うるさい」場合があります。しかし、特定のルールを無視するよう静的解析ツールを設定する追加の手順を踏むことで、この問題は解決されます。
静的解析ルールに基づくコードの修正
静的解析ツールの大半では、ルールの修正はプログラマーに委ねられるため、プログラマーはルール違反の原因を理解し、修正方法を知っている必要がある。
静的解析ツールのうち、違反を修正する機能を提供するものはごくわずかです。修正は多くの場合、チーム、使用されている技術、および合意されたコーディングスタイルに依存するためです。
標準規則
静的解析ツールが標準ルールで構成されている場合、ルールの品質に対する誤った信頼が生じることがあります。プログラマーが遭遇する可能性のある全ての問題や、ルールが適用されるべきあらゆる状況を網羅していると信じたくなるものです。ルールが適用されるべき状況は時に微妙であり、容易に認識できない場合もあります。
プログラマーが静的解析ツールを使用し、規則と違反をより詳細に調査することで、自身の専門領域における文脈で問題を認識し回避する能力を身につけることが期待される。
ドメインにコンテキストルールが必要な場合、静的解析ツールにはドメインやライブラリに対応するルールが存在しない可能性があり、さらにこれらのツールは設定や拡張が困難な場合が多い。
厄介事
これらの「厄介事」はどれも克服できないものではない:
- 偽陽性
- 修正不足
- ルールを無視するための設定
- コンテキスト固有のルールの追加
しかし、これらは静的解析ツールの使用を最初から避けるための言い訳として頻繁に用いられており、非常に残念なことである。なぜなら、静的解析の利用は以下のような点で極めて有用となり得るからだ:
- 若手開発者向けの優れたアプローチを強調する
- 明確なコーディング違反について迅速なフィードバックを受け取れます
- プログラマーがこれまで遭遇したことのない難解な問題を特定する
- プログラマーが適切なコーディング手法を選択したことを確認する(違反が報告されない限り)
IDEベースの静的解析ツール
プロジェクトの単独参加者として、私はIDE内で実行される静的解析ツールを好んで使用し、コードに対する迅速なフィードバックを得ています。
これは、プロジェクトが持つ可能性のあるプルリクエストレビュープロセスとCI統合を補完します。
私は、自分に優位性をもたらし、個々の作業フローを改善するツールを見つけようとしています。
IDE内でツールが実行されると、それらは通常同じ基本的なGUIと設定アプローチを使用するため、それらを同義と見なしたくなるかもしれません。
ツールには重複する機能やルールセットがあるかもしれませんが、最大限の利点を得るために、複数のツールをインストールしてそれぞれの強みを活用します。
コーディング時に積極的に使用している静的解析用IDEツールは以下の通りです:
- 組み込みのIntelliJインスペクション — 一般的なコーディングパターン
- SpotBugs — よくあるエラー
- SonarLint — 一般的な使用パターン
- CheckStyle - 一般的なスタイルパターン
- Secure Code Warrior Sensei Secure Code Warrior カスタムルールの作成
私はそれらすべてを使用しています。なぜなら、それらは互いに補い合い、補完し合うためにうまく連携するからです。
IntelliJインスペクション
IntelliJを使用している場合、すでにそのインスペクションを利用しています。
これらはIDEでマークされる静的解析のルールです。一部のルールには、問題を修正するためにコードを書き換えることができるクイックフィックスオプションも備わっています。
ルールは有効化および無効化が可能であり、IDE内で強調表示されるエラーレベルを選択できます。

優れたIntelliJインスペクションは数多く存在します。私がこれを書いている間にそれらをすべて確認したので、そのことは承知しています。私はデフォルト設定のままIntelliJインスペクションを使用しており、特に設定を変更していませんが、インスペクションの効果を最大限に活用するには、それらを精査し、自身のコーディングスタイルに関連するものを特定し、警告レベルをコード内で確実に気づけるように設定すべきです。
IntelliJのインスペクションの素晴らしい点は、IDEに無料で含まれており、以下の「筋肉記憶」を構築するのに役立つことです:
- ソースコードを記述中に警告とエラーを検出する
- マークされたコードの上にマウスカーソルを移動すると、ルール違反を確認できます
- Alt+Enter キーを押して、問題に対するクイックフィックスを適用してください

バグを検出する
バグの検出IntelliJプラグインは静的解析を使用して、コード内のエラーを通知します。
SpotBugsはIntelliJの設定で、コードをスキャンするように構成できます。実際に使用されるルールは「検出器」タブで確認できます。

私はコードを書き終えて確認した後、SpotBugsを使用する傾向があります。その後、「テストソースを含むプロジェクトファイルを解析する」オプションを実行します。

これにより、エラーやデッドコード、明らかな最適化箇所を特定できます。また、報告された違反事項を調査するよう促され、対応策の判断に役立ちます。
SpotBugsは問題を検出しますが、問題を解決しようとするクイックフィックス操作は提供しません。
SpotBugsは設定が簡単で、IDE内で得られる有用な客観的なセカンドオピニオンだと考えています。
ソナー・リント
Sonar Lintプラグイン。
SonarLintは、IntelliJの設定で、コードの検証に使用するルールを選択するために構成できます。

デフォルトでは、SonarLintはリアルタイムで実行され、現在編集中のコードの問題を表示します。
SonarLintは即効性のある解決策を提供しませんが、違反レポートに付随するドキュメントは通常、明確でよく文書化されています。
私はこれまで、SonarLintが新しいJava機能について知らせてくれるのに有用だと感じてきました。それらは、私が新しいバージョンのJavaで知っていたものです。
まだ確認中
スタイルチェックこのプラグインは、書式設定ルールとコード品質ルールの組み合わせを提供します。
CheckStyleプラグインは「Sun Checks」および「Google Checks」とセットで提供されます。
CheckStyleは、プロジェクトが独自のルールセットを作成する時間を費やした場合に最大の価値を提供します。その後、IDEプラグインをそのルールセットを使用するように設定でき、プログラマーはコードをCIに送信する前にスキャンを実行できます。
CheckStyleは、CheckStyle違反の数が閾値を超えた場合に、CIプロセス向けのビルド失敗プラグインとして非常に頻繁に使用されます。
Sensei
Sensei 静的解析を実行し、抽象構文木(AST)に基づいてコードを照合し、クイックフィックスを生成します。これにより、問題のあるコードを非常に特定的に識別することが可能になります。
ASTにより、レシピに関連付けられたクイックフィックスは周囲のコードを理解できます。例えば、コードに新しいクラスが追加された場合、そのクラスのインポートはソースファイルに1回だけ追加され、置換ごとに追加されることはありません。
Sensei 、他のツールでは存在しない、あるいは設定が難しい可能性のあるカスタムマッチングルールを簡単に作成できるようにSensei 。
設定ファイルを変更する代わりに、GUIで設定全体を操作できます。 新規レシピ作成時には、GUI上でそのレシピがどのコードに適用されるかを容易に把握できます。またQuickFixes定義時には、コードの修正前後の状態を即座に比較可能です。これにより、チームや技術、さらには個々のプログラマーに特化した、文脈に即したレシピの作成が容易になります。

Sensei 静的Sensei 。例えば、ほとんどの静的解析ツールは問題を検出しますが、修正は行いません。Sensei 一般的な使用例Sensei 、他のツールの適切な検索をSensei 、クイックフィックスで拡張Sensei 。これにより、適用されるカスタム修正がプロジェクトのコーディング基準に既に準拠しているという利点があります。
Senseiを作成しています。これらは既にIntelliJのIntentionsセットに含まれているものですが、Intentionsレポートが私が作成したコンテキストに完全には合致しない場合や、IntelliJが提供するQuickFixが私が使用したいコードパターンに合わない場合のためです。
既存のツールを完全に置き換えるのではなく、それらを補完します。
Sensei 、一般的なルールの文脈に応じたバリエーションを特定する場合にも非常にSensei 。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジン内の一般的なSQLルールは引き続き適用されます。Sensei 、これらのSensei バリエーションを作成できます。
Sensei 、前述の静的解析ツールのような汎用的なレシピを多くSensei 。その強みは、特定のコーディングスタイルやユースケースに合わせて設定されたクイックフィックスを含む、新しいレシピの作成を容易にする点にあります。
注記:汎用的なユースケースをカバーするレシピの公開アーカイブを現在作成中です。 こちらで確認できます。
要約
私は、連携し、設定可能で、特定の状況に合わせて拡張しやすいツールを選ぶ傾向があります。長年、IDE内の静的解析ツールを使用して問題を特定し、使用しているプログラミング言語やライブラリについて学んできました。
私は上記のツールをすべて組み合わせて使用しています:
- IntelliJ Intentionsは、頻繁に発生するコードの問題を即座に認識し、多くの場合関連するクイックフィックスを提供します。
- SpotBugsは、私が見落としていたかもしれない単純なエラーを見つけ、パフォーマンスの問題について警告してくれます。
- SonarLintは、私が知らなかったJavaの機能を見つけ出し、コードをさらにモデル化するように促します。
- CheckStyleは、合意されたコーディングスタイルを遵守するのに役立ち、CIプロセス中にもそのスタイルが適用されるようにします。
- Sensei 、静的解析ツールで検出される一般的なシナリオを拡張するためのクイックフィックスの作成をSensei 、他のツールでは設定が困難な特定のプロジェクトや技術に関するレシピを作成します。
---
IntelliJSensei をインストールするには、「Preferences\ Plugins」(Mac)または「Settings\ Plugins」(Windows)を開き、「Sensei Code」を検索してください。
Secure Code Warrior のGitHubアカウントにある`sensei`Secure Code Warrior 、一般的なユースケース向けのサンプルコードとレシピのリポジトリをご覧いただけます。
https://github.com/securecodewarrior/sensei-blog-examples
静的解析とは何か?
静的解析とは、アプリケーションを実行せずにソースコードを自動解析することである。
プログラムの実行中に分析が行われる場合、それは動的解析と呼ばれます。
静的解析は、以下のことを特定するために頻繁に使用されます:
- セキュリティ上の脆弱性。
- 性能問題。
- 規格不適合
- 古いプログラミング構文の使用
静的解析ツールはどのように機能しますか?
静的解析ツールに共通する基本的な概念は、ソースコードを走査して特定のコーディングパターンを識別し、それらに警告や情報を関連付けることである。
これは「JUnit 5のテストクラスは必ずしも'public'である必要はない」という単純なものから、「SQL実行文で使用される信頼できない文字列入力」のように特定が複雑なものまで様々です。
静的解析ツールは、この機能を実装する方法において異なる。
- 抽象構文木(AST)を生成するためのソースコード解析技術
- 正規表現によるテキスト比較
- 上記に挙げたものの組み合わせ。
正規表現によるテキストの照合は非常に柔軟で、照合ルールを容易に記述できますが、多くの誤検知を引き起こすことが多く、照合ルールは周囲のコードコンテキストを認識しません。
ASTマッチングはソースコードを単なるテキストファイルではなくプログラムコードとして扱います。これにより、より具体的かつ文脈に応じた照合が可能となり、コードに対して報告される誤検知の数を削減できます。
継続的インテグレーションにおける静的解析
静的解析は、継続的インテグレーション(CI)プロセス中に頻繁に実行され、コンプライアンス問題に関するレポートを生成します。このレポートを確認することで、コードベースの経時的な客観的な概要を把握できます。
一部のユーザーは、静的解析ツールを特定のコード部分のみを測定し、規則のサブセットについてのみ報告するように設定することで、静的解析をコード品質の客観的な尺度として使用しています。
客観性は使用されるルールによって保証される。なぜなら、それらはコードの評価において時間の経過とともに変化しないからである。使用されるルールの組み合わせとその設定が主観的な判断であることは明らかであり、異なるチームは異なる時期に異なるルールを使用することを選択する。
CIで静的解析を実行することは有用だが、プログラマーへのフィードバックが遅れる可能性がある。プログラマーはコーディング中にフィードバックを受け取らず、後でコードが静的解析ツールを通過した際に初めてフィードバックを得る。さらに、CIで静的解析を実行する副次的な効果として、結果を無視しやすくなるという点が挙げられる。
チームに静的解析の結果にもっと注意を払わせるためには、通常、ビルドプロセスでしきい値メトリクスを設定することが可能です。これにより、メトリクス(例えば、トリガーされたルールの数)が超過した場合にビルドが失敗します。
静的解析をIDEで
より迅速なフィードバックを得るために、多くのIDEプラグインが用意されています。これらは、コード変更時に必要に応じて、あるいは定期的に、静的解析ルールをIDE内で実行します。
規則違反は、プログラマーがコードを記述している間、IDE上で表示されることがあります。規則の無視を困難にするため、違反箇所はエディタ内で下線付きのコードとして表示されるよう設定できる場合が多いです。
個人的には、特に静的解析ツールがカバーする新しいライブラリを扱う際に、コーディングを改善する有用な方法だと考えています。ただし、誤検知や関心のないルールに関しては「うるさい」場合があります。しかし、特定のルールを無視するよう静的解析ツールを設定する追加の手順を踏むことで、この問題は解決されます。
静的解析ルールに基づくコードの修正
静的解析ツールの大半では、ルールの修正はプログラマーに委ねられるため、プログラマーはルール違反の原因を理解し、修正方法を知っている必要がある。
静的解析ツールのうち、違反を修正する機能を提供するものはごくわずかです。修正は多くの場合、チーム、使用されている技術、および合意されたコーディングスタイルに依存するためです。
標準規則
静的解析ツールが標準ルールで構成されている場合、ルールの品質に対する誤った信頼が生じることがあります。プログラマーが遭遇する可能性のある全ての問題や、ルールが適用されるべきあらゆる状況を網羅していると信じたくなるものです。ルールが適用されるべき状況は時に微妙であり、容易に認識できない場合もあります。
プログラマーが静的解析ツールを使用し、規則と違反をより詳細に調査することで、自身の専門領域における文脈で問題を認識し回避する能力を身につけることが期待される。
ドメインにコンテキストルールが必要な場合、静的解析ツールにはドメインやライブラリに対応するルールが存在しない可能性があり、さらにこれらのツールは設定や拡張が困難な場合が多い。
厄介事
これらの「厄介事」はどれも克服できないものではない:
- 偽陽性
- 修正不足
- ルールを無視するための設定
- コンテキスト固有のルールの追加
しかし、これらは静的解析ツールの使用を最初から避けるための言い訳として頻繁に用いられており、非常に残念なことである。なぜなら、静的解析の利用は以下のような点で極めて有用となり得るからだ:
- 若手開発者向けの優れたアプローチを強調する
- 明確なコーディング違反について迅速なフィードバックを受け取れます
- プログラマーがこれまで遭遇したことのない難解な問題を特定する
- プログラマーが適切なコーディング手法を選択したことを確認する(違反が報告されない限り)
IDEベースの静的解析ツール
プロジェクトの単独参加者として、私はIDE内で実行される静的解析ツールを好んで使用し、コードに対する迅速なフィードバックを得ています。
これは、プロジェクトが持つ可能性のあるプルリクエストレビュープロセスとCI統合を補完します。
私は、自分に優位性をもたらし、個々の作業フローを改善するツールを見つけようとしています。
IDE内でツールが実行されると、それらは通常同じ基本的なGUIと設定アプローチを使用するため、それらを同義と見なしたくなるかもしれません。
ツールには重複する機能やルールセットがあるかもしれませんが、最大限の利点を得るために、複数のツールをインストールしてそれぞれの強みを活用します。
コーディング時に積極的に使用している静的解析用IDEツールは以下の通りです:
- 組み込みのIntelliJインスペクション — 一般的なコーディングパターン
- SpotBugs — よくあるエラー
- SonarLint — 一般的な使用パターン
- CheckStyle - 一般的なスタイルパターン
- Secure Code Warrior Sensei Secure Code Warrior カスタムルールの作成
私はそれらすべてを使用しています。なぜなら、それらは互いに補い合い、補完し合うためにうまく連携するからです。
IntelliJインスペクション
IntelliJを使用している場合、すでにそのインスペクションを利用しています。
これらはIDEでマークされる静的解析のルールです。一部のルールには、問題を修正するためにコードを書き換えることができるクイックフィックスオプションも備わっています。
ルールは有効化および無効化が可能であり、IDE内で強調表示されるエラーレベルを選択できます。

優れたIntelliJインスペクションは数多く存在します。私がこれを書いている間にそれらをすべて確認したので、そのことは承知しています。私はデフォルト設定のままIntelliJインスペクションを使用しており、特に設定を変更していませんが、インスペクションの効果を最大限に活用するには、それらを精査し、自身のコーディングスタイルに関連するものを特定し、警告レベルをコード内で確実に気づけるように設定すべきです。
IntelliJのインスペクションの素晴らしい点は、IDEに無料で含まれており、以下の「筋肉記憶」を構築するのに役立つことです:
- ソースコードを記述中に警告とエラーを検出する
- マークされたコードの上にマウスカーソルを移動すると、ルール違反を確認できます
- Alt+Enter キーを押して、問題に対するクイックフィックスを適用してください

バグを検出する
バグの検出IntelliJプラグインは静的解析を使用して、コード内のエラーを通知します。
SpotBugsはIntelliJの設定で、コードをスキャンするように構成できます。実際に使用されるルールは「検出器」タブで確認できます。

私はコードを書き終えて確認した後、SpotBugsを使用する傾向があります。その後、「テストソースを含むプロジェクトファイルを解析する」オプションを実行します。

これにより、エラーやデッドコード、明らかな最適化箇所を特定できます。また、報告された違反事項を調査するよう促され、対応策の判断に役立ちます。
SpotBugsは問題を検出しますが、問題を解決しようとするクイックフィックス操作は提供しません。
SpotBugsは設定が簡単で、IDE内で得られる有用な客観的なセカンドオピニオンだと考えています。
ソナー・リント
Sonar Lintプラグイン。
SonarLintは、IntelliJの設定で、コードの検証に使用するルールを選択するために構成できます。

デフォルトでは、SonarLintはリアルタイムで実行され、現在編集中のコードの問題を表示します。
SonarLintは即効性のある解決策を提供しませんが、違反レポートに付随するドキュメントは通常、明確でよく文書化されています。
私はこれまで、SonarLintが新しいJava機能について知らせてくれるのに有用だと感じてきました。それらは、私が新しいバージョンのJavaで知っていたものです。
まだ確認中
スタイルチェックこのプラグインは、書式設定ルールとコード品質ルールの組み合わせを提供します。
CheckStyleプラグインは「Sun Checks」および「Google Checks」とセットで提供されます。
CheckStyleは、プロジェクトが独自のルールセットを作成する時間を費やした場合に最大の価値を提供します。その後、IDEプラグインをそのルールセットを使用するように設定でき、プログラマーはコードをCIに送信する前にスキャンを実行できます。
CheckStyleは、CheckStyle違反の数が閾値を超えた場合に、CIプロセス向けのビルド失敗プラグインとして非常に頻繁に使用されます。
Sensei
Sensei 静的解析を実行し、抽象構文木(AST)に基づいてコードを照合し、クイックフィックスを生成します。これにより、問題のあるコードを非常に特定的に識別することが可能になります。
ASTにより、レシピに関連付けられたクイックフィックスは周囲のコードを理解できます。例えば、コードに新しいクラスが追加された場合、そのクラスのインポートはソースファイルに1回だけ追加され、置換ごとに追加されることはありません。
Sensei 、他のツールでは存在しない、あるいは設定が難しい可能性のあるカスタムマッチングルールを簡単に作成できるようにSensei 。
設定ファイルを変更する代わりに、GUIで設定全体を操作できます。 新規レシピ作成時には、GUI上でそのレシピがどのコードに適用されるかを容易に把握できます。またQuickFixes定義時には、コードの修正前後の状態を即座に比較可能です。これにより、チームや技術、さらには個々のプログラマーに特化した、文脈に即したレシピの作成が容易になります。

Sensei 静的Sensei 。例えば、ほとんどの静的解析ツールは問題を検出しますが、修正は行いません。Sensei 一般的な使用例Sensei 、他のツールの適切な検索をSensei 、クイックフィックスで拡張Sensei 。これにより、適用されるカスタム修正がプロジェクトのコーディング基準に既に準拠しているという利点があります。
Senseiを作成しています。これらは既にIntelliJのIntentionsセットに含まれているものですが、Intentionsレポートが私が作成したコンテキストに完全には合致しない場合や、IntelliJが提供するQuickFixが私が使用したいコードパターンに合わない場合のためです。
既存のツールを完全に置き換えるのではなく、それらを補完します。
Sensei 、一般的なルールの文脈に応じたバリエーションを特定する場合にも非常にSensei 。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジン内の一般的なSQLルールは引き続き適用されます。Sensei 、これらのSensei バリエーションを作成できます。
Sensei 、前述の静的解析ツールのような汎用的なレシピを多くSensei 。その強みは、特定のコーディングスタイルやユースケースに合わせて設定されたクイックフィックスを含む、新しいレシピの作成を容易にする点にあります。
注記:汎用的なユースケースをカバーするレシピの公開アーカイブを現在作成中です。 こちらで確認できます。
要約
私は、連携し、設定可能で、特定の状況に合わせて拡張しやすいツールを選ぶ傾向があります。長年、IDE内の静的解析ツールを使用して問題を特定し、使用しているプログラミング言語やライブラリについて学んできました。
私は上記のツールをすべて組み合わせて使用しています:
- IntelliJ Intentionsは、頻繁に発生するコードの問題を即座に認識し、多くの場合関連するクイックフィックスを提供します。
- SpotBugsは、私が見落としていたかもしれない単純なエラーを見つけ、パフォーマンスの問題について警告してくれます。
- SonarLintは、私が知らなかったJavaの機能を見つけ出し、コードをさらにモデル化するように促します。
- CheckStyleは、合意されたコーディングスタイルを遵守するのに役立ち、CIプロセス中にもそのスタイルが適用されるようにします。
- Sensei 、静的解析ツールで検出される一般的なシナリオを拡張するためのクイックフィックスの作成をSensei 、他のツールでは設定が困難な特定のプロジェクトや技術に関するレシピを作成します。
---
IntelliJSensei をインストールするには、「Preferences\ Plugins」(Mac)または「Settings\ Plugins」(Windows)を開き、「Sensei Code」を検索してください。
Secure Code Warrior のGitHubアカウントにある`sensei`Secure Code Warrior 、一般的なユースケース向けのサンプルコードとレシピのリポジトリをご覧いただけます。
https://github.com/securecodewarrior/sensei-blog-examples

以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
レポートを見るデモを予約するアラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。
静的解析とは何か?
静的解析とは、アプリケーションを実行せずにソースコードを自動解析することである。
プログラムの実行中に分析が行われる場合、それは動的解析と呼ばれます。
静的解析は、以下のことを特定するために頻繁に使用されます:
- セキュリティ上の脆弱性。
- 性能問題。
- 規格不適合
- 古いプログラミング構文の使用
静的解析ツールはどのように機能しますか?
静的解析ツールに共通する基本的な概念は、ソースコードを走査して特定のコーディングパターンを識別し、それらに警告や情報を関連付けることである。
これは「JUnit 5のテストクラスは必ずしも'public'である必要はない」という単純なものから、「SQL実行文で使用される信頼できない文字列入力」のように特定が複雑なものまで様々です。
静的解析ツールは、この機能を実装する方法において異なる。
- 抽象構文木(AST)を生成するためのソースコード解析技術
- 正規表現によるテキスト比較
- 上記に挙げたものの組み合わせ。
正規表現によるテキストの照合は非常に柔軟で、照合ルールを容易に記述できますが、多くの誤検知を引き起こすことが多く、照合ルールは周囲のコードコンテキストを認識しません。
ASTマッチングはソースコードを単なるテキストファイルではなくプログラムコードとして扱います。これにより、より具体的かつ文脈に応じた照合が可能となり、コードに対して報告される誤検知の数を削減できます。
継続的インテグレーションにおける静的解析
静的解析は、継続的インテグレーション(CI)プロセス中に頻繁に実行され、コンプライアンス問題に関するレポートを生成します。このレポートを確認することで、コードベースの経時的な客観的な概要を把握できます。
一部のユーザーは、静的解析ツールを特定のコード部分のみを測定し、規則のサブセットについてのみ報告するように設定することで、静的解析をコード品質の客観的な尺度として使用しています。
客観性は使用されるルールによって保証される。なぜなら、それらはコードの評価において時間の経過とともに変化しないからである。使用されるルールの組み合わせとその設定が主観的な判断であることは明らかであり、異なるチームは異なる時期に異なるルールを使用することを選択する。
CIで静的解析を実行することは有用だが、プログラマーへのフィードバックが遅れる可能性がある。プログラマーはコーディング中にフィードバックを受け取らず、後でコードが静的解析ツールを通過した際に初めてフィードバックを得る。さらに、CIで静的解析を実行する副次的な効果として、結果を無視しやすくなるという点が挙げられる。
チームに静的解析の結果にもっと注意を払わせるためには、通常、ビルドプロセスでしきい値メトリクスを設定することが可能です。これにより、メトリクス(例えば、トリガーされたルールの数)が超過した場合にビルドが失敗します。
静的解析をIDEで
より迅速なフィードバックを得るために、多くのIDEプラグインが用意されています。これらは、コード変更時に必要に応じて、あるいは定期的に、静的解析ルールをIDE内で実行します。
規則違反は、プログラマーがコードを記述している間、IDE上で表示されることがあります。規則の無視を困難にするため、違反箇所はエディタ内で下線付きのコードとして表示されるよう設定できる場合が多いです。
個人的には、特に静的解析ツールがカバーする新しいライブラリを扱う際に、コーディングを改善する有用な方法だと考えています。ただし、誤検知や関心のないルールに関しては「うるさい」場合があります。しかし、特定のルールを無視するよう静的解析ツールを設定する追加の手順を踏むことで、この問題は解決されます。
静的解析ルールに基づくコードの修正
静的解析ツールの大半では、ルールの修正はプログラマーに委ねられるため、プログラマーはルール違反の原因を理解し、修正方法を知っている必要がある。
静的解析ツールのうち、違反を修正する機能を提供するものはごくわずかです。修正は多くの場合、チーム、使用されている技術、および合意されたコーディングスタイルに依存するためです。
標準規則
静的解析ツールが標準ルールで構成されている場合、ルールの品質に対する誤った信頼が生じることがあります。プログラマーが遭遇する可能性のある全ての問題や、ルールが適用されるべきあらゆる状況を網羅していると信じたくなるものです。ルールが適用されるべき状況は時に微妙であり、容易に認識できない場合もあります。
プログラマーが静的解析ツールを使用し、規則と違反をより詳細に調査することで、自身の専門領域における文脈で問題を認識し回避する能力を身につけることが期待される。
ドメインにコンテキストルールが必要な場合、静的解析ツールにはドメインやライブラリに対応するルールが存在しない可能性があり、さらにこれらのツールは設定や拡張が困難な場合が多い。
厄介事
これらの「厄介事」はどれも克服できないものではない:
- 偽陽性
- 修正不足
- ルールを無視するための設定
- コンテキスト固有のルールの追加
しかし、これらは静的解析ツールの使用を最初から避けるための言い訳として頻繁に用いられており、非常に残念なことである。なぜなら、静的解析の利用は以下のような点で極めて有用となり得るからだ:
- 若手開発者向けの優れたアプローチを強調する
- 明確なコーディング違反について迅速なフィードバックを受け取れます
- プログラマーがこれまで遭遇したことのない難解な問題を特定する
- プログラマーが適切なコーディング手法を選択したことを確認する(違反が報告されない限り)
IDEベースの静的解析ツール
プロジェクトの単独参加者として、私はIDE内で実行される静的解析ツールを好んで使用し、コードに対する迅速なフィードバックを得ています。
これは、プロジェクトが持つ可能性のあるプルリクエストレビュープロセスとCI統合を補完します。
私は、自分に優位性をもたらし、個々の作業フローを改善するツールを見つけようとしています。
IDE内でツールが実行されると、それらは通常同じ基本的なGUIと設定アプローチを使用するため、それらを同義と見なしたくなるかもしれません。
ツールには重複する機能やルールセットがあるかもしれませんが、最大限の利点を得るために、複数のツールをインストールしてそれぞれの強みを活用します。
コーディング時に積極的に使用している静的解析用IDEツールは以下の通りです:
- 組み込みのIntelliJインスペクション — 一般的なコーディングパターン
- SpotBugs — よくあるエラー
- SonarLint — 一般的な使用パターン
- CheckStyle - 一般的なスタイルパターン
- Secure Code Warrior Sensei Secure Code Warrior カスタムルールの作成
私はそれらすべてを使用しています。なぜなら、それらは互いに補い合い、補完し合うためにうまく連携するからです。
IntelliJインスペクション
IntelliJを使用している場合、すでにそのインスペクションを利用しています。
これらはIDEでマークされる静的解析のルールです。一部のルールには、問題を修正するためにコードを書き換えることができるクイックフィックスオプションも備わっています。
ルールは有効化および無効化が可能であり、IDE内で強調表示されるエラーレベルを選択できます。

優れたIntelliJインスペクションは数多く存在します。私がこれを書いている間にそれらをすべて確認したので、そのことは承知しています。私はデフォルト設定のままIntelliJインスペクションを使用しており、特に設定を変更していませんが、インスペクションの効果を最大限に活用するには、それらを精査し、自身のコーディングスタイルに関連するものを特定し、警告レベルをコード内で確実に気づけるように設定すべきです。
IntelliJのインスペクションの素晴らしい点は、IDEに無料で含まれており、以下の「筋肉記憶」を構築するのに役立つことです:
- ソースコードを記述中に警告とエラーを検出する
- マークされたコードの上にマウスカーソルを移動すると、ルール違反を確認できます
- Alt+Enter キーを押して、問題に対するクイックフィックスを適用してください

バグを検出する
バグの検出IntelliJプラグインは静的解析を使用して、コード内のエラーを通知します。
SpotBugsはIntelliJの設定で、コードをスキャンするように構成できます。実際に使用されるルールは「検出器」タブで確認できます。

私はコードを書き終えて確認した後、SpotBugsを使用する傾向があります。その後、「テストソースを含むプロジェクトファイルを解析する」オプションを実行します。

これにより、エラーやデッドコード、明らかな最適化箇所を特定できます。また、報告された違反事項を調査するよう促され、対応策の判断に役立ちます。
SpotBugsは問題を検出しますが、問題を解決しようとするクイックフィックス操作は提供しません。
SpotBugsは設定が簡単で、IDE内で得られる有用な客観的なセカンドオピニオンだと考えています。
ソナー・リント
Sonar Lintプラグイン。
SonarLintは、IntelliJの設定で、コードの検証に使用するルールを選択するために構成できます。

デフォルトでは、SonarLintはリアルタイムで実行され、現在編集中のコードの問題を表示します。
SonarLintは即効性のある解決策を提供しませんが、違反レポートに付随するドキュメントは通常、明確でよく文書化されています。
私はこれまで、SonarLintが新しいJava機能について知らせてくれるのに有用だと感じてきました。それらは、私が新しいバージョンのJavaで知っていたものです。
まだ確認中
スタイルチェックこのプラグインは、書式設定ルールとコード品質ルールの組み合わせを提供します。
CheckStyleプラグインは「Sun Checks」および「Google Checks」とセットで提供されます。
CheckStyleは、プロジェクトが独自のルールセットを作成する時間を費やした場合に最大の価値を提供します。その後、IDEプラグインをそのルールセットを使用するように設定でき、プログラマーはコードをCIに送信する前にスキャンを実行できます。
CheckStyleは、CheckStyle違反の数が閾値を超えた場合に、CIプロセス向けのビルド失敗プラグインとして非常に頻繁に使用されます。
Sensei
Sensei 静的解析を実行し、抽象構文木(AST)に基づいてコードを照合し、クイックフィックスを生成します。これにより、問題のあるコードを非常に特定的に識別することが可能になります。
ASTにより、レシピに関連付けられたクイックフィックスは周囲のコードを理解できます。例えば、コードに新しいクラスが追加された場合、そのクラスのインポートはソースファイルに1回だけ追加され、置換ごとに追加されることはありません。
Sensei 、他のツールでは存在しない、あるいは設定が難しい可能性のあるカスタムマッチングルールを簡単に作成できるようにSensei 。
設定ファイルを変更する代わりに、GUIで設定全体を操作できます。 新規レシピ作成時には、GUI上でそのレシピがどのコードに適用されるかを容易に把握できます。またQuickFixes定義時には、コードの修正前後の状態を即座に比較可能です。これにより、チームや技術、さらには個々のプログラマーに特化した、文脈に即したレシピの作成が容易になります。

Sensei 静的Sensei 。例えば、ほとんどの静的解析ツールは問題を検出しますが、修正は行いません。Sensei 一般的な使用例Sensei 、他のツールの適切な検索をSensei 、クイックフィックスで拡張Sensei 。これにより、適用されるカスタム修正がプロジェクトのコーディング基準に既に準拠しているという利点があります。
Senseiを作成しています。これらは既にIntelliJのIntentionsセットに含まれているものですが、Intentionsレポートが私が作成したコンテキストに完全には合致しない場合や、IntelliJが提供するQuickFixが私が使用したいコードパターンに合わない場合のためです。
既存のツールを完全に置き換えるのではなく、それらを補完します。
Sensei 、一般的なルールの文脈に応じたバリエーションを特定する場合にも非常にSensei 。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジン内の一般的なSQLルールは引き続き適用されます。Sensei 、これらのSensei バリエーションを作成できます。
Sensei 、前述の静的解析ツールのような汎用的なレシピを多くSensei 。その強みは、特定のコーディングスタイルやユースケースに合わせて設定されたクイックフィックスを含む、新しいレシピの作成を容易にする点にあります。
注記:汎用的なユースケースをカバーするレシピの公開アーカイブを現在作成中です。 こちらで確認できます。
要約
私は、連携し、設定可能で、特定の状況に合わせて拡張しやすいツールを選ぶ傾向があります。長年、IDE内の静的解析ツールを使用して問題を特定し、使用しているプログラミング言語やライブラリについて学んできました。
私は上記のツールをすべて組み合わせて使用しています:
- IntelliJ Intentionsは、頻繁に発生するコードの問題を即座に認識し、多くの場合関連するクイックフィックスを提供します。
- SpotBugsは、私が見落としていたかもしれない単純なエラーを見つけ、パフォーマンスの問題について警告してくれます。
- SonarLintは、私が知らなかったJavaの機能を見つけ出し、コードをさらにモデル化するように促します。
- CheckStyleは、合意されたコーディングスタイルを遵守するのに役立ち、CIプロセス中にもそのスタイルが適用されるようにします。
- Sensei 、静的解析ツールで検出される一般的なシナリオを拡張するためのクイックフィックスの作成をSensei 、他のツールでは設定が困難な特定のプロジェクトや技術に関するレシピを作成します。
---
IntelliJSensei をインストールするには、「Preferences\ Plugins」(Mac)または「Settings\ Plugins」(Windows)を開き、「Sensei Code」を検索してください。
Secure Code Warrior のGitHubアカウントにある`sensei`Secure Code Warrior 、一般的なユースケース向けのサンプルコードとレシピのリポジトリをご覧いただけます。
https://github.com/securecodewarrior/sensei-blog-examples
目次
アラン・リチャードソンは、20年以上にわたり、開発者として、またテスターからテスト責任者まで、あらゆるレベルのテストに携わってきたプロフェッショナルなIT経験を持っています。アラン・リチャードソンは、Secure Code Warrior のデベロッパーリレーションズの責任者として、チームと直接連携し、高品質で安全なコードの開発を促進しています。また、「Dear Evil Tester」や「Java For Testers」など4冊の著書があります。また、テクニカルWebテストやSelenium WebDriver with Javaを学ぶためのオンライントレーニングcourses を作成しています。アランは、SeleniumSimplified.com、EvilTester.com、JavaForTesters.com、CompendiumDev.co.ukに執筆やトレーニングビデオを掲載している。

Secure Code Warrior 、ソフトウェア開発サイクル全体を通じてコードの安全性を確保し、サイバーセキュリティを最優先とする文化を構築するため、貴社をSecure Code Warrior 。アプリセキュリティ管理者、開発者、CISO、あるいはセキュリティに関わるあらゆる立場の方々に対し、当社が貴社のビジネスにおける不安全なコードに関連するリスクの低減を支援します。
デモを予約するダウンロード入門リソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.




.png)