LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

静的解析ツールの4系統と役割の違い

静的解析・コード品質ゲートとは、ソースコードを実行せずに機械的に検査し、あらかじめ定めた基準を満たさないコードの統合を止める仕組みを指します。対象領域によってツールの系統が異なり、1種類で全体を担うことはできません。

OWASP（Open Web Application Security Project）が公開する「Source Code Analysis Tools」ページ^*1では、静的解析ツールを「Static Application Security Testing（SAST）ツール」と呼び、ソースコードまたはコンパイル済みコードを解析してセキュリティ上の欠陥を発見する仕組みと位置づけています。

SASTはSQLインジェクションやクロスサイト・スクリプティングといった、コード上のセキュリティ欠陥を検出する系統です。IPA（情報処理推進機構）の「安全なウェブサイトの作り方」改訂第7版^*2は、SQLインジェクション・OSコマンド・インジェクション・クロスサイト・スクリプティングなど11種類の脆弱性を挙げ、根本的な解決策と保険的対策を整理しています。SASTツールが検出対象とする欠陥の多くは、この分類に沿っています。

リンター・フォーマッタはSASTとは異なる系統で、命名規則・インデント・未使用変数といったコーディングスタイルの一貫性を検査します。セキュリティ欠陥ではなく可読性・保守性を対象にする点が違いです。複雑度・重複検出は、関数の分岐の多さやコードの重複箇所を数値化し、保守しにくいコードを早期に把握する系統です。

SCA（Software Composition Analysis、ソフトウェア構成分析）は、自社が書いたコードではなく、利用しているオープンソースの依存ライブラリに既知の脆弱性が含まれていないかを調べる系統です。OWASPの同ページ^*1でも「SCA（software composition analysis）はオープンソースの脆弱性をスキャンするツール」として紹介されており、SASTとは検査対象が異なります。自社コードの欠陥はSAST、外部ライブラリの脆弱性はSCAという役割分担になります。

品質ゲートをCI/CDへ組み込む基本設計

品質ゲート（Quality Gate）とは、コード分析時に測定する一連の条件をあらかじめ定義し、その条件を満たさない場合はマージやリリースを進めない仕組みです。SonarSourceのSonarQube Cloud公式ドキュメント^*3では、品質ゲートの目的を「開発者に、問題を修正すべきかコードをマージすべきかを判断させる指標を提供すること」と説明しています。

同ドキュメントは、品質ゲートの条件を「新規コード（New Code）」と「全体的なコード」の両方に対して設定できるとしています。新規コードに対しては、バグ・脆弱性・保守性の問題を導入しないこと、新規に生じたSecurity Hotspot（セキュリティ上注意すべき箇所）がすべてレビュー済みであること、新規コードの十分なテストカバレッジを確保すること、新規コード内の重複を制限することを、代表的な条件として挙げています。

CI/CD（継続的インテグレーション・継続的デリバリー）に品質ゲートを組み込む場合、一般的な流れは次の通りです。開発者がコードをリポジトリにプッシュすると、CIパイプラインが静的解析ツールを自動実行します。解析結果が品質ゲートの条件を満たさない場合、パイプラインを失敗させてマージを止めます。プルリクエスト単位で新規コードの条件のみを適用する運用と、メインブランチでは新規コードと全体コードの両方を評価する運用を、SonarQube Cloudのドキュメント^*3は区別しています。

この設計により、品質ゲートは「一度導入したら終わり」の仕組みではなく、CIの一部として常時実行される検査工程になります。ツールを導入するだけでなく、どの条件を「ブロックする基準」にし、どの条件を「警告に留める基準」にするかという設計判断が、運用の成否を分けます。

アラート疲れと全量ブロックが招く現場の失敗

静的解析の導入自体を誤ると、現場で運用が続かなくなる典型的な失敗パターンが2つあります。第一に、検出された警告を大量に出したまま放置する運用です。重大度を区別せずすべての指摘を表示すると、開発者はどれに対応すべきか判断できなくなり、警告を確認しない状態が定着します。この状態は一般に「アラート疲れ」と呼ばれます。

第二に、既存コード全体を品質ゲートの対象にして、基準を満たさないコードをまとめてブロックする運用です。新規に構築するプロジェクトでなければ、既存のコードベースには長年の開発で積み重なった指摘事項が相当数存在します。これを一度にすべて解消しなければマージできない設定にすると、通常の開発が止まり、現場から静的解析そのものへの抵抗感が生まれます。

この2つの失敗は根が共通しています。検出範囲と適用範囲を絞らずに導入すると、開発者が対応すべき指摘の量が多すぎて実務に組み込めなくなります。静的解析ツールの導入で成果を出すには、ツールを入れることではなく、検出結果のうち「今すぐ対応する範囲」をどう絞るかという設計が要点になります。

新規コード基準で品質ゲートを機能させる運用

アラート疲れと全量ブロックを避ける実務上の対処が、前述した「新規コード」基準での品質ゲート運用です。SonarQube Cloudのドキュメント^*4は、新規コードを「最近追加または修正されたコード」と定義し、新規コードと既存コードを区別して別々のメトリクスを計算する仕組みを説明しています。

同ドキュメントは、新規コードに焦点を当てる理由を「新規コードの状態を強調することで、新規コードに対する取り組みに集中できるようにする」ためだとしています。既存コードをすべて一度に対象にするのではなく、新しい変更箇所に品質ゲートの基準を適用し、既存の指摘は段階的に減らしていく方針です。

この運用では、リリース済みの既存コードに残る指摘は即時のブロック対象にせず、次にそのファイルへ変更を加えるタイミングで解消していく前提を置きます。新規コードに絞ることで、開発チームが対応すべき指摘の量を管理可能な水準に保ちながら、コードベース全体の品質を時間をかけて高めていく設計です。

あわせて、重大度による優先順位づけも欠かせません。セキュリティ上の欠陥に関する指摘と、命名規則のような軽微なスタイル指摘を同列に扱うと、対応の優先度が曖昧になります。品質ゲートのブロック条件には重大な指摘のみを含め、軽微な指摘は警告表示に留めるといった重大度別の切り分けが、現場での運用継続を左右します。

外注の委託範囲と発注側が準備する情報

静的解析・品質ゲートの導入を外部パートナーに委託する場合、委託範囲は大きく初期構築と継続伴走の2段階に分かれます。初期構築では、対象言語・フレームワークに適したSAST・SCA・リンターの選定、既存コードの解析結果を踏まえたルールセットの整備、CI/CDパイプラインへの組込みを行います。

初期構築を内製で行う場合、対象言語ごとの静的解析ツールの特性の把握、既存コードベースの解析結果の読み解き、CI/CDパイプラインの設定変更という複数分野の知識が必要になります。特に、既存コードの指摘量が多い場合にどこまでを新規コード基準に切り出すかという設計判断には、複数プロジェクトでの導入経験が影響します。

継続伴走では、運用開始後に発生する誤検知（false positive）の調整、重大度別の閾値の見直し、新しいルールの追加といったチューニングを継続します。品質ゲートは一度設定すれば完成する仕組みではなく、プロジェクトの実情に合わせて条件を調整し続ける前提があります。導入直後に基準を厳しくしすぎると、前述のアラート疲れや全量ブロックの失敗を再現するため、運用開始後の調整を担う体制をあらかじめ確保しておくことが望ましいといえます。

発注側が準備しておく情報としては、対象リポジトリの言語・フレームワークの一覧、既存のCI/CD環境（利用しているサービス・パイプラインの構成）、現在のコードレビュー体制、セキュリティ要件（準拠すべき基準がある場合はその名称）が挙げられます。これらの情報が事前に整理されているほど、ツール選定とルール整備の初期構築を短い期間で進めやすくなります。

LASSICは、システム開発の受託・保守運用を行う中で、CI/CDパイプラインの構築や既存システムのコード品質を継続的に管理する体制を担ってきました。静的解析ツールの選定からCI組込み、運用開始後のルール調整まで、開発チームの実情に合わせた導入を支援する体制を整えています。

まとめ：静的解析導入を外注で進める3つの判断軸

本稿では、静的解析ツールを使った品質ゲートの導入について整理しました。要点を3つに集約すると次の通りです。第一に、SAST・リンター・複雑度検出・SCAは検査対象が異なる別系統のツールであり、目的に応じて組み合わせる必要があります。第二に、品質ゲートは既存コード全体ではなく新規コードの差分に基準を絞ることで、アラート疲れと全量ブロックという2つの典型的な失敗を避けられます。第三に、外注時は初期構築（ツール選定・ルール整備・CI組込み）と継続伴走（チューニング）を分けて委託範囲を定義し、発注側は対象リポジトリの言語・CI環境・セキュリティ要件を事前に整理しておくことが、導入を円滑に進める前提になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OWASP「Source Code Analysis Tools」（https://owasp.org/www-community/Source_Code_Analysis_Tools）
2. *2　出典：独立行政法人情報処理推進機構（IPA）「安全なウェブサイトの作り方」改訂第7版（2021年）（https://www.ipa.go.jp/security/vuln/websecurity/index.html）
3. *3　出典：SonarSource「Introduction to quality gates」SonarQube Cloudドキュメント（https://docs.sonarsource.com/sonarqube-cloud/standards/managing-quality-gates/introduction-to-quality-gates.md）
4. *4　出典：SonarSource「About new code」SonarQube Cloudドキュメント（https://docs.sonarsource.com/sonarqube-cloud/standards/about-new-code.md）

Tweet