はじめに
静的コード分析は、バグ、セキュリティ脆弱性、コードの臭い、および企業のコーディング標準に合致しないその他の問題を特定する、広く利用されている自動化されたコード検査技術です。開発プロセスの早い段階で実行され、コードの品質と保守性の向上に貢献します。
静的コード解析ツールであるSonarQube Serverを使用することで、本番環境で重大な問題となる前にコード上の問題を検出・修正できます。ソフトウェア開発ライフサイクル（SDLC）の早期段階でコーディング上の問題を特定することで、より効率的で信頼性の高いソフトウェアの開発が可能となります。さらに、開発プロセスの早い段階で問題を解決することは、アプリケーションのテスト段階や本番環境へのデプロイ後に問題に対処する場合と比較して、時間とコストの削減につながります。
この記事では、静的コード分析の仕組み、コードベースの品質向上にどのように役立つか、そしてSonarQube Community BuildとSonarQube for IDEを使用した静的コード分析の実行方法について学びます。
静的コード分析とは？
静的コード分析は、ソースコードを実行せずに体系的に検査する基本的なソフトウェア品質保証技術であり、開発ライフサイクルの早期段階でバグ、脆弱性、コードの臭い、コンプライアンス問題を検出することを目的としています。強力な静的解析ツールとアルゴリズムを活用することで、開発者や組織はソフトウェアが本番環境に到達する前に、セキュリティリスクの特定、コードの完全性の維持、コーディング標準の順守、技術的負債の最小化を実現できます。
静的コード分析を実施する主な理由は以下の通りです：
- バグが本番環境に影響を与える前に捕捉する。SDLCの最も早い段階で発見されたバグは されます。
- セキュリティ脆弱性を明らかにし、本番環境での悪用を防止する。.
- 重複コードや未使用コードを排除することで保守性を向上させる。.
- チームメンバー間でコードスタイルを統一し、コードレビューを形式的な差異ではなく意図に集中させる。.
- 技術的負債に対処する範囲の定義を支援する。.
静的コード分析は開発の様々な初期段階で実行可能です。リンターはライブ増分コード分析を適用し、入力中にエラーや不審なコードをフラグ付けします。リポジトリへのコミット後（post-commit）も、SDLCにおいてコード分析を実行する有益な段階です。
Sonarは、IDE向けSonarQubeを用いたローカル開発環境での静的コード分析チェックの実行、およびDevOpsプラットフォームに統合されたSonarQube Serverを用いたCIパイプラインの一部としての実行を推奨します。両方を実行するのは冗長に思えるかもしれませんが、二つの目的を果たします。第一に、IDEで問題を可能な限り早期に捕捉し、手戻りを最小限に抑えること。第二に、IDEでは発見が困難で、プロジェクトの全コードとその依存関係を走査するリポジトリ環境でのみ検出可能な、コードの深層に潜む問題を発見することです。
SonarQube Serverによる静的コード分析の実装
SonarQube Serverは、Java、Python、Go、JavaScript、TypeScript、C、C++、C#など30以上の言語でバグ、脆弱性、コードの臭いを特定・排除する強力な静的コード分析ツールです。
ワークフローへのSonarQube Server統合はコード品質と保守性を向上させ、最終的にユーザーへより信頼性の高い製品を提供します。包括的なルールセットとカスタマイズ可能な設定により、業界のベストプラクティスに準拠しながら、よりクリーンで効率的なコードの記述を支援します。
SonarQube Serverでは、様々な設定で静的コード分析を実行できます：
- コードベース全体に対して、いつでもオンデマンドでコード分析を実行。
- GitHub、GitLab、BitbucketなどのDevOpsプラットフォーム上で、コードリポジトリへの変更をコミットおよびプッシュするたびにコード分析を実行するよう設定。
- SonarQube for IDE（SonarQube Serverで設定されたコード品質ルールを利用するIDE拡張機能）を使用すれば、JetBrains IDE（IntelliJ）、Visual Studio、VS Code、JetBrains IDE、EclipseなどのIDEで変更を加えながら、即座にコード分析フィードバックを得られます。
SonarQube Community Buildで静的コード分析を実行する手順を確認しましょう。SonarQube ServerとCommunity Buildはセルフマネージド製品のため、サーバーのホスティング先とインストール場所を決定する必要があります。クラウドホスト型SaaS環境を好む場合は、SonarQube Cloudを利用することも可能です。本ガイドではライセンス不要で実行可能なSonarQube Community Buildのインストール手順を説明します。インストール手順はSonarQube Serverと同一ですが、分析を開始するにはライセンスの追加インストールが必要です。
SonarQube Community Buildのインストール
既にSonarQube ServerまたはCommunity Buildインスタンスが稼働している場合は、このセクションをスキップできます。
SonarQube Community Buildは、ZIPファイルからWindows/Mac/Linuxマシンにローカルインストールするか、Dockerイメージからコンテナとして実行できます。
このチュートリアルでは、プラットフォームを簡単に探索できる方法であり、最も一般的な実行方法であるため、DockerコンテナでSonarQube Community Buildを実行します。もう1つの利点は、本番環境での実行に切り替える際に、データベース内のデータを再構築せずに利用できることです。
ローカルマシンでDockerコンテナを実行するには、Docker Desktopがインストールされ、実行されている必要があります。
次に、`sq-community-build` という名前の新しいディレクトリを作成します。その中に 『sq-logs』 というディレクトリと 『docker-compose.yml』 という新しいファイルを作成し、以下のスクリプトをファイルに貼り付けます：
version: "3"
services:
sonarqube:
image: sonarqube:community
ports:
- "9000:9000"
depends_on:
- db
environment:
SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
SONAR_JDBC_USERNAME: sonar
SONAR_JDBC_PASSWORD: sonar
volumes:
- sonarqube_data:/opt/sonarqube/data
- sonarqube_extensions:/opt/sonarqube/extensions
- ./sq-logs:/opt/sonarqube/logs
db:
image: postgres
ports:
- 5433:5432
environment:
POSTGRES_USER: sonar
POSTGRES_PASSWORD: sonar
POSTGRES_DB: sonar
volumes:
- postgresql:/var/lib/postgresql
- postgresql_data:/var/lib/postgresql/data
volumes:
sonarqube_data:
sonarqube_extensions:
postgresql:
postgresql_data:あるいは、GitHubにある当社のサンプルdocker-compose.ymlファイルを使用することもできます。上記の脚本は今回の演習向けに少し簡素化されているため、説明が容易です。
SonarQube Buildを実行する前に、上記のymlスクリプトが定義している内容をいくつか確認しておきましょう。そうすれば謎が解けます。
まず、Dockerコンテナ内でSonarQube Community Buildを実行するサービスを定義します。イメージは「sonarqube:community」であり、データベースに依存している点に注意してください。使用するデータベースはPostgreSQLであり、SonarQube Community Buildに対してデータベースのログイン認証情報とデータベースのURL（ホスト名、ポート、スキーマを含む）を指定します。
SonarQube Community Buildが必要とする3つのボリュームと、コンテナポートへのホストポートマッピングを定義します。このポートは、SonarQube Community Buildとのインターフェースに使用するWebサーバーにアクセスするためのポートです。スクリプトがSonarQube Community Buildのログ保存用フォルダを定義している点に注意してください。問題発生時にログを確認する必要がある場合、その場所が分かります。ログは『sq-docker/sq-logs/』に保存されます。
次に、ymlスクリプトは別のDockerコンテナ内でPostgreSQLを実行するサービスを定義します。スクリプトはデータベースのホストポートとコンテナポートのマッピングを定義します。SonarQube Community Buildが以前に使用したログインユーザー名とパスワードを設定するための環境変数を渡しています。さらに、スクリプトはSonarQube Community Buildが使用する「sonar」というスキーマをデータベースに設定します。最後に、データベースの実行に必要なボリュームの場所を定義します。また、両方のコンテナに必要なボリュームも定義します。
ターミナルで「sq-community-build」ディレクトリ内に移動し、以下のコマンドを実行します：
docker compose up
SonarQube Community BuildとPostgreSQLの動作状況を示す大量の出力が表示されます。出力が減速し、「SonarQube Community Build is operational」というメッセージが表示されたら、ブラウザで`localhost:9000/`にアクセスしてSonarQube Community Buildを開きます。デフォルトの認証情報（ユーザー名 `admin`、パスワード `admin`）でログインし、プロンプトが表示されたらデフォルトパスワードを変更してください。
SonarQube Community Build の基本操作
デフォルトパスワードを変更すると、SonarQube Community Build が最初のプロジェクト作成をガイドします。プロジェクトが DevOps CI プラットフォームにある場合は、そのプラットフォームとの連携を設定するか、ローカルマシン上のプロジェクトを分析するよう SonarQube Community Build を設定できます。
最初のプロジェクトを設定してスキャンする前に、このページの各領域を確認し、SonarQube Community Build が表示する内容について理解しましょう。
ページのメイン部分から、以下のいずれかを実行できます:
- SonarQube Community Build を GitHub、GitLab、Bitbucket、Azure DevOps などの DevOps プラットフォームに接続し、リポジトリ内の分析対象プロジェクトを指定します。SonarQube Community Build はプロジェクト全体に対してコード分析を実行し、リポジトリのメインブランチへのコミットごとに増分的に分析を行います。
- SonarQube Community Buildをコードベースのローカル作業コピーに接続し、オンデマンドでローカルにコードスキャンを実行する。
このウィザードを使用して追加したものを含め、SonarQube Community Buildに追加したすべてのプロジェクトは、SonarQube Community BuildのナビゲーションメニューにあるProjectsセクションからアクセスできます。
ナビゲーションメニューのその他のセクションには以下が含まれます：
- Issues このセクションには、SonarQube Community Buildがプロジェクト分析の結果検出したすべての課題が含まれます。課題はプロジェクトごと、および検出されたファイルごとにグループ化されています。左側のナビゲーションを使用して、課題リストをフィルタリングし、目的の課題を見つけることができます。
- Rules これは、SonarQube Community Buildでサポートされているすべてのプログラミング言語において利用可能な、静的コード分析ルールの包括的なリストです。
- Quality Profiles これらは、分析中に適用される言語固有のルールの集合です。各言語には、その言語に対してSonarが推奨するルールを含むSonar wayというデフォルトプロファイルがあります。自社のニーズに合わせてカスタムプロファイルを作成することもできますが、最も一般的に使用されるのはデフォルトのSonar wayです。
- Quality Gates このセクションでは、すべての品質ゲートを一覧表示します。品質ゲートには、コードスキャンを失敗させる条件が含まれます。デフォルトの品質ゲート「Sonar way」には、Sonarが推奨する手法に基づく一連の条件が含まれています。これは、古いコードと新しいコードを区別し、SonarQube Community Buildの使用開始後に追加された新しいコードが、バグ、セキュリティ脆弱性、技術的負債を含まず、適切なテストカバレッジを有していることを保証します。品質プロファイルと同様に、企業ポリシーに合致する条件付きのカスタム品質ゲートを作成できますが、SonarQube Community Buildが事前設定する条件が標準となります。
SonarQube Community Buildのオンデマンド分析実行
本番環境では通常、SonarQube Community BuildをDevOpsプラットフォームに接続し、スキャン対象プロジェクトを追加します。簡潔にするため、SonarQube Community Buildでローカル環境のオンデマンドコードスキャンを実行する方法を見てみましょう。この演習を実行するには、稼働中のSonarQube Community BuildとPostgreSQLのDockerコンテナ、およびプロジェクトリポジトリのローカルコピーのみが必要です。
テスト対象として、ASP.NET Core のリファレンスアプリケーションであるeShopOnWebを使用します。GitHubで`eShopOnWeb`のフォークを作成し、ローカルマシンにクローンしてください。
ローカルインストール環境では `localhost:9000/projects/create` でアクセス可能な SonarQube Community Build のプロジェクト作成画面に戻ります。「手動」Manually ローカル作業コピーのオンデマンド分析を設定します。
次の画面で、Project display nameに `eShopOnWeb` と入力します。Set Upをクリックします。
次の画面で、Locallyをクリックしてローカル作業コピーを分析することを選択してください。
次の画面「Analyze your project」で、Provide a tokenの下にあるデフォルトのトークンオプションを受け入れ、Generateをクリックします。トークンが生成されたら、Continueをクリックします。
Run analysis on your projectで、.NETを選択します。Choose your build toolでは、.NET Coreを選択したままにします。SonarQube Community Buildは、ローカルコードスキャンを実行するために必要な追加コマンドの実行手順を表示します：
お使いのマシンに最新版の.NETがインストールされていない場合は、.NET Core SDKをダウンロードしてインストールし、手順を実行してください。
ターミナルで以下のコマンドを実行し、SonarQube Community Buildのスキャナー.NET Coreグローバルツールをインストールします：
dotnet tool install --global dotnet-sonarscanner
コマンドの出力が.NETツールディレクトリがPATH環境変数に含まれていないと表示した場合、出力内の指示に従ってPATHに追加してください。
ターミナルで`eShopOnWeb`フォークのローカルコピーのルートフォルダを開き、SonarQube Community Buildの「スキャナーの実行」に記載されている3つのコマンドを実行します。このうち2番目のコマンド`dotnet build`を`dotnet build Everything.sln`に変更してください。
ターミナルで、`eShopOnWeb`フォークのローカルコピーのルートフォルダを開き、SonarQube Community BuildのExecute the scannerに記載されている3つのコマンドを実行してください。これらのコマンドのうち2番目の`dotnet build`を`dotnet build Everything.sln`に変更してください。
これらのコマンドがすべて完了し、結果がSonarQube Community Buildインストールに送信されると、SonarQube Community Buildプロジェクトページに初期コードスキャンの結果の概要が表示されます。:
ご覧の通り、SonarQube Community Buildは`eShopForWeb`で使用されている様々な言語において、20のバグ、31のセキュリティホットスポット、151のコード臭を検出しました。この概要画面でコード臭の数をクリックすると、具体的な問題のリストが表示されます。左側のLanguageフィルターをクリックすると、これらのコード臭が発生している言語がわかります。このケースでは、大半がC#コードに由来していますが、CSSファイルで1件のコード臭が検出されています。
プロジェクト概要に戻ると、サマリーはコード全体に関するものであることがわかります。New Codeタブが空欄なのは、初期コードスキャンのみを実行したためです：
コードに変更を加える際、SonarQube Community Buildはこの初期分析を基準として使用し、新しいコードで検出された問題を報告します。新しいコードに対する品質ゲートにより、コードの健全性を維持し、問題がコードベースに流入するのを防ぎます。その結果、コードベース全体の品質は時間の経過とともに徐々に向上していきます。
`UriComposer`クラスのコンストラクタをprivateに変更し、`eShopOnWeb`に新たなバグを導入した場合、SonarQube Community Buildコードスキャンを再度実行すると以下の現象が発生します：
SonarQube Community Buildのデフォルト品質ゲートでは新規バグの導入が禁止されているため、新規コードの品質ゲートは失敗します。修正を行い、SonarQube Community Buildを再びグリーン状態にするよう促されます。
VS CodeにおけるSonarQube for IDEの接続モードの使用
SonarQube Community Buildは、コードをオンデマンドでスキャンしたり、リポジトリへの新規プッシュ時に自動スキャンしたりしますが、SonarQube for IDEを使えば、IDE内でコード品質に関するフィードバックを即座に得られます。これは無料の高度なIDE拡張機能であり、コードを入力している最中やコミット前にコード品質を維持するのに役立ちます。
Visual Studio Code を使用している場合は、Extensions ペインを開き、SonarQube for IDE を検索し、検索結果から SonarQube for IDE 拡張機能をインストールして、install SonarQube for IDE: Visual Studio Code をインストールしてください。
コードを記述している間、IDE上でSonarQube Community Buildのようなコード分析結果が表示されます:
IDE内でのコード分析にSonarQube for IDEを、リポジトリ内でのコード分析にSonarQube Community Buildを併用している場合、Connected ModeではSonarQube for IDEとSonarQube Community Buildを連携させることで初めて利用可能な高度な機能が解放されます。例えばConnected Modeでは、SonarQube for IDEがSonarQube Community Buildで設定したコード品質ルールに基づいてコードの問題をフラグ付けします。
まとめ
使用する技術スタックに関わらず、静的コード分析ツールを日常のプログラミングワークフローに導入することで、クリーンコードの維持と本番環境でのバグ追跡に費やす時間の削減が可能になります。
本記事では、SonarQube Serverにおける静的コード分析の仕組み、IDE内でのSonarQube for IDEの使用方法、そして両ツールを連携させる方法について学びました。
このガイドはJura Gorohovskyによって執筆されました。
- 2024年8月5日