1. はじめに

SonarQube：単なるツールではなく、プラットフォームへ

SonarQubeは世界中の多くの企業で使用されているコード品質管理プラットフォームであり、IT関連コミュニティでも活発に言及される、かなり認知度の高い静的解析プラットフォームです。
ただ残念な点は、SonarQubeというプラットフォームが「JavaやJavaScript開発者のための静的解析ツール」程度に認識されているケースが多かったことでした。

SonarQubeは単なる開発ツールを超え、SRE、インフラ運用者、セキュリティ担当者全員にとって強力なガバナンスプラットフォームです。Java、Python、Goなどの主要開発言語だけでなく、TerraformのようなIaC（Infrastructure as Code）分析をサポートしており、インフラセキュリティ自動化の核心ツールとして活用できます。
加えて、静的に分析した項目を提供するだけでなく、該当項目に対する分析を深堀りし、開発者と運用者、開発者とセキュリティ担当者、セキュリティ担当者と運用者など、いわゆるDevSecOps環境において多角的にコミュニケーションおよび分析管理ができる立体的な機能などを提供します。

本記事の目的

この記事では、単に開発段階ではなく、Ops段階以降からどのように活用できるかを、GitLab CIとSonarQubeを連携・設定したデモを通じて紹介します。

開発者ではなくSRE/運用者の視点から：

どのようなセキュリティ問題が検知されるか
ダッシュボードをどのようにモニタリングするか
例外処理と監査対応はどのように行うか

に焦点を当てます。

アプリケーションを実装する言語を通じてデモを構成する方法もありますが、この記事ではIaCでインフラを構築するコードを探知する例を通して説明したいため、Terraformでデモを構築してみました。

2. このシステムが解決する課題

SREやインフラ運用者の立場で最も恐れる瞬間は、「誰かが誤ったTerraformコードを本番環境（プロダクション）に適用した時」です。

S3バケットがパブリックに公開されデータが流出したり
RDSが暗号化なしで作成されコンプライアンス違反が発生したり
IAMポリシーが過度に開放されセキュリティ事故につながったり

開発チームが迅速にインフラをプロビジョニングすることは良いことですが、セキュリティ検討なしでデプロイされることは、運用チームにとって悪夢です。

従来方式の限界

問題	説明
手動レビュー依存	PRレビュアーがセキュリティ問題を見逃す可能性がある
事後対応	デプロイ後にセキュリティスキャン → すでに手遅れ
標準化の欠如	チームごとに異なる基準でコードを作成
監査追跡の困難さ	「誰がなぜこのように設定したのか」という記録がない

SonarQube + GitLab CI 導入後

改善点	説明
自動ブロック	セキュリティ問題があればマージ自体が不可能
事前予防	コードがメインブランチに入る前に検出
中央集権ポリシー	Quality Profileで全社のセキュリティ基準を統一
監査ログ	すべての問題と例外処理の履歴が記録される

3. アーキテクチャ概要

3.1 全体フロー

3.2 なぜ tfsec や Checkov ではなく SonarQube なのか

Terraformのセキュリティスキャンツールは数多く存在します。tfsecやCheckovのような専用CLIツールも非常に優れています。しかし、運用・管理の観点において、SonarQubeには明確な差別化要因があります。

観点	tfsec / Checkov	SonarQube
ポリシー管理	ローカル設定ファイルに分散	Quality Profileによる中央集中管理
技術的負債の管理	全体スキャンのみ可能	New Code / Overall Code の分離
監査追跡	コード内コメントでの例外処理	UI上での承認プロセス + 監査ログ
マルチ言語	Terraform 専用	Kotlin, Python, Java などの統合分析
ダッシュボード	CLI 出力	Web UIで非開発者も確認可能

特に**「New Code」という概念**は、既存のレガシーコードベースに導入する際に決定的な要素となります。過去の技術的負債と現在進行中の変更を明確に分離して管理できるため、導入のハードルが著しく下がります。

「New Code」の概念はSonarQubeの最もユニークな特徴の一つですが、記事の分量と主題を絞るため、ここでは詳しく触れません。
詳細については以下のリンクをご参照ください。

4. 実際の検知事例

今回のデモプロジェクトでは、SonarQubeによる検知を確認するため、あえて脆弱性を含むコードをいくつかプッシュし、CI/CDパイプライン経由でSonarQubeがスキャンを実行するよう設定しました。
SonarQubeは「Quality Gates」という仕組みを通じて、コード規約（Convention）はもちろん、脆弱性やセキュリティリスクのある箇所をチェックしてスコアリングします。このスコアは、ビルドやデプロイ可否の判断基準となります。

現在のプロジェクトでは、SonarQubeが13件のSecurity Hotspotsを検知しました。

SonarQubeにおける「Security Hotspots」とは、セキュリティ上の懸念がある箇所を指摘する機能です。
これは即座にバグと断定されるものではなく、人間がレビューを行うことで「本当に問題（脅威）なのか、そうでないか」を判断すべき項目として表示されます。

Security Hotspots 全体リスト画面（13件）

4.1 Security Hotspots：権限関連（Permission）- 5件

Permission カテゴリ詳細画面

検知メッセージ	重要度	発生原因の例
"Make sure allowing public ACL/policies to be set is safe here"	Medium	`aws_s3_bucket_public_access_block` において、`block_public_acls` または `block_public_policy` が `false` に設定されている
"No Public Access Block configuration prevents public ACL/policies to be set on this S3 bucket"	Medium	S3バケットに `aws_s3_bucket_public_access_block` リソースが紐付けられていない
"Make sure granting public access is safe here"	Medium	S3バケットポリシーにて `Principal = "*"` とし、全ユーザーへのアクセスを許可している
"Make sure granting access to all resources is safe here"	Medium	IAMポリシーにて `Resource = "*"` とし、全リソースへのアクセスを許可している

これらの検知の中から、一つを取り上げて見てみましょう。

問題となるコード例：

resource "aws_s3_bucket_public_access_block" "secure" {
  bucket = aws_s3_bucket.secure_bucket.id

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

検知された各事例の詳細を確認すると、上記のように、どのソースコードファイルのどの箇所が問題になっているのかを表示してくれます。

この項目がどのような根拠に基づいて、レビューが必要な懸念箇所としてチェックされたのかも確認できます。
SonarQubeでは、言語ごとに「ルール（Rule）」が定義されており、これに基づいてチェックが行われます。各ルールには固有のIDが割り当てられています。
今回検知された項目は、SonarQubeのterraform:S6281というルールによって検出されたものであり、そのルールの詳細な説明や根拠が確認できるよう表示されています。

該当の項目を確認すると、その項目に関する詳細情報を参照できます。また、その問題を解決するために必要な予測時間（Remediation Effort）も表示されるため、プロジェクト全体の技術的負債を算出することも可能です。

これらのルールは、単にSonarQubeが独自に判断して決定したものではなく、各サービスプロバイダーや標準化団体などが定めた基準や規則を根拠としています。
terraform:S6281についても、以下のようにAWS公式ドキュメントの推奨事項や、ソフトウェア脆弱性の分類標準であるCWE（Common Weakness Enumeration）などを根拠として策定されたルールであることが確認できます。

Security Hotspotsでは、このルールがどのようなリスクを孕んでいるのか、またどのように修正すべきかについてのガイドラインも確認することができます。

修正後のコード：

resource "aws_s3_bucket_public_access_block" "secure" {
  bucket = aws_s3_bucket.secure_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

4.2 Security Hotspots：その他（Others）- 1件

Security Hotspotsには、一般的な推奨事項をチェックする項目も含まれています。
例えば、以下の検知項目は、技術的・セキュリティ的に重大なリスクがあるわけではありませんが、バックアップを取得していなかったり、バックアップの保持期間（Retention Period）が極端に短く設定されているケースに対して、推奨（Advisory）の意味合いで検知されるものです。

検知メッセージ	重要度	発生原因
"Make sure that defining a short backup retention duration is safe here"	Low	`aws_db_instance`において、`backup_retention_period`が0、または非常に短い期間に設定されており、災害復旧（DR）が困難である

これにより、バックアップ頻度を見直すきっかけとなったり、意図的にバックアップを行わない設定（あるいは特定の頻度設定）にしている場合は、該当ルールをQuality Gatesの検知対象から除外する運用も可能です。

4.3 Issue（課題）の検知

SonarQubeには、Security Hotspots以外に「Issue」という機能が存在します。
Security Hotspotsが推奨事項やレビューが必要な「疑わしい箇所」を検知するものであるのに対し、Issueは「必ず修正すべき」コードのバグ、脆弱性、Code Smell（コードの不吉な臭い）があると判断された項目を指します。

これらはSeverity Level（重要度）として表現され、その深刻度に応じて以下のように分類されます。

Severity	説明	修正優先度	例
Blocker	即時修正が必須、デプロイ不可	即時	ハードコーディングされたパスワード、SQLインジェクション
High	深刻なセキュリティ/安定性の問題	早急な修正が必要	認証回避、リソースリーク
Medium	運用に影響を与えうる問題	計画的な修正	例外処理の欠落、パフォーマンス問題
Low	品質低下の要素	余裕がある時	コーディング規約違反、軽微な複雑度
Info	改善提案レベル	選択的	コメントスタイル、命名ガイド

今回のデモプロジェクトでは、優先度が比較的高めである「High」項目にて、2つの問題が検知されました。

その中から一つずつ見ていきましょう。

まずは、This policy is vulnerable to the "Update Lambda code" privilege escalation vector. Remove permissions or restrict the set of resources they apply to という項目についてです。

IAMポリシーが、Lambdaコードの更新権限を全リソース（*）に対して付与しているため、指摘された項目です。
これにより、攻撃者がこのポリシーを持つロールを乗っ取った場合、すべてのLambda関数コードを悪意を持って改ざんすることが可能になるため、SonarQube側で「必ず修正すべきコード」であると判断しました。

当該Issueに対する修正指針についても、AWSのベストプラクティス（Best Practice）に基づき、以下のようにガイドされていることが確認できます。

最後に、This policy is vulnerable to the "Create Access Key" privilege escalation vector. Remove permissions or restrict the set of resources they apply to. という項目についても、簡単に見てみましょう。

IAMユーザーおよびポリシー作成時に、権限を過剰に付与（IAMCreateAccessKey）しているために検知された項目です。
なぜこれが問題となるのか、その詳細な説明についても、該当Issueの詳細ページにて確認できます。

ブラウザの翻訳機能で「日本語」に変換した内容であるため、一部不自然な表現が含まれている可能性があります。

5. パイプライン構成

Terraformの場合、CI/CDパイプラインを構築する際は、validateを実行し、その後にplan、そしてapplyでプロビジョニングを行うのが一般的なフローとなります。
plan/applyを実行する前、あるいはコードをマージする前に、品質チェックを活用することで、プロビジョニングの実行可否を制御することが可能です。
以下は、その設定の一部を抜粋したものです。

5.1 GitLab CI 設定 (.gitlab-ci.yml)

variables:
  SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
  GIT_DEPTH: "0"  # 全Git履歴が必要（New Code計算用）
  TF_VERSION: "1.5.0"

stages:
  - validate
  - security-scan

# Terraform構文チェック
terraform-validate:
  stage: validate
  image:
    name: hashicorp/terraform:${TF_VERSION}
    entrypoint: [""]
  script:
    - terraform init -backend=false
    - terraform validate

# SonarQubeセキュリティスキャン
sonarqube-check:
  stage: security-scan
  image:
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: [""]
  script:
    - sonar-scanner 
        -Dsonar.host.url="${SONAR_HOST_URL}" 
        -Dsonar.token="${SONAR_TOKEN}"
        -Dsonar.qualitygate.wait=true
   
  allow_failure: false  # ← Quality Gate失敗時にパイプラインを停止
   
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'main'

Quality Gateの基準をクリアできない場合、警告として扱われ、次のステージへは進みません。

重要なポイント：

sonar.qualitygate.wait=true: 分析完了まで待機
allow_failure: false: Quality Gate失敗時にパイプラインを失敗させる → MRのマージ不可

5.2 SonarQubeプロジェクト設定 (sonar-project.properties)

# プロジェクト識別子
sonar.projectKey=Qiita-DEMO
sonar.projectName=Terraform Security Analysis Demo
sonar.projectVersion=1.0

# 分析対象
sonar.sources=terraform
sonar.sourceEncoding=UTF-8

# ノイズ除去
sonar.exclusions=**/.terraform/**,**/*.tfstate,**/*.tfstate.backup

# AWS Provider v4+ 構文サポート
sonar.terraform.provider.aws.version=4.60.0

6. SRE/運用者はどのように活用すべきか

6.1 ダッシュボードのモニタリング

SonarQubeのWeb UIで確認できる情報と活用法は以下の通りです。

メニュー	確認内容	活用
Overview	全体のセキュリティ状態、Quality Gate通過可否	日次チェック
Security Hotspots	レビューが必要なセキュリティ問題リスト	課題のトリアージ
Measures	メトリクス詳細（複雑度、重複など）	トレンド分析
Activity	分析履歴、変化の推移	週間/月間レポート

6.2 例外処理（Safe）

ビジネス要件により、セキュリティルールを意図的に違反（許容）しなければならない場合があります。例えば以下のようなケースです。

外部公開用WebサイトのS3バケット
開発環境の一時的な設定

この時、コードにコメントを記述する代わりに、SonarQubeのUI上で例外処理を行います。

Security Hotspot をクリック
Review ボタンをクリック
"Safe" を選択
理由を入力（例：「外部公開Webサイト用S3 - 承認者：OOO、日付：2025-12-06」）

これが重要である理由：

コードをコメントで汚すことがない
監査時に「なぜこのように設定したのか」という証跡として活用可能
誰が、いつ、なぜ例外処理したのかの履歴管理が可能

6.3 Quality Gate のカスタマイズ

デフォルトの Quality Gate が厳しすぎたり、逆に緩すぎたりする場合は調整可能です：

SonarQube → Quality Gates メニュー
新しい Quality Gate を作成、または既存のものをコピー
条件を修正：
- "Security Hotspots Reviewed = 100%"（全ての Hotspot のレビューを必須とする）
- "New Security Hotspots < 5"（新規 Hotspot を5件未満とする）
プロジェクトに適用

ケースによっては、問題が多い場合でも、カスタマイズを行うことでこのように PASS（通過）させることも可能です。

7. 導入効果

指標	Before	After
セキュリティ問題の発見時点	デプロイ後	コードレビュー段階
レビュー時間	手動チェック 30分以上	自動スキャン 1分
標準準拠率	チームごとに異なる	100% 強制
監査対応	手動によるドキュメント化	自動ログ
セキュリティ事故	事後対応	事前予防

8. おわりに

SonarQubeは、単なる「開発者用Lintツール」ではありません。

SRE/運用者の視点から：

もはや「これ、なぜこのように設定したんですか？」と追及する必要がなくなります
Quality Gateを通過しなければ、そもそもマージができません
例外処理もシステムに記録されるため、監査対応が容易になります

組織の視点から：

セキュリティポリシーを、コードではなくプラットフォームで一元管理できます
開発スピードを維持しながら、セキュリティレベルを向上させます
「人がミスをしてもシステムが防いでくれる」ガバナンスを構築できます

SonarQubeは活用の仕方次第で、開発チームだけでなく、SRE、セキュリティチーム、コンプライアンス担当者の全員が活用できる幅広いプラットフォームになり得ます。IDEとの連携を通じて開発段階からセキュリティ要素のフィードバックを受けられるのはもちろん、ビルド/デプロイ段階でもGitLab/GitHubなどのプラットフォームと連携し、一貫した基準でセキュリティ要素を管理できるプラットフォームは、そう多くはないと私は考えています。

この記事で使用した環境は、Self-Hosted GitLabとSelf-Hosted SonarQubeをAWS環境に構築して構成したものです。公開ネットワーク環境が許可されないエンタープライズ規模の環境でも十分に構築・活用できる構成であり、小規模な組織でも容易に導入・活用できるため、皆さんも一度活用してみてはいかがでしょうか。