3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yuken(Yuken Matsuda)
in

【次なるSAST】Amazon Q DeveloperとAmazon inspector code securityの比較

3
Last updated at Posted at 2026-02-26

はじめに

先日、私が投稿したCodeGuruSecurityは惜しくも、25年11月を持ってサービス終了となってしまいました。
公式アナウンスでは後継サービスは「Amazon Q Developer(以下、Q Devloper」の利用を推奨していましたが、Pro版となると＄19/ユーザーですので、開発者が10名もいれば、それだけで3万円/月ぐらい飛んでいきます。
もちろんSAST以外の幅広い利用もありますが、すでにCopilotなどのエージェントをIDE統合しているチームも多いのではないかと思います。

そこで、この記事ではCodeGuru Securityの後継であるAmazonQ Developerと、似たSAST機能を持つAmazon Inspector code security(以下、Inspector code security)を比較し、自チームに合うSASTを選択していきたいと思います。

SASTとは

Static Application Security Testingの略で、日本語では静的アプリケーションセキュリティテストと呼ばれます。
プログラムを実際に動かさず、ソースコードを解析してセキュリティ上の欠陥（脆弱性）を見つけるテスト手法。

Q Developerと Inspector code securityについて

比較表にまとめます。

比較項目 Q Developer (Pro版) Inspector Code Security
概要 AI駆動型開発支援
AIがコードを理解し、開発の全工程（実装・レビュー・修正）をサポートする統合ツール		 継続的な脆弱性スキャン
セキュリティ監査やコンプライアンス維持に特化した脆弱性検知サービス
特徴（強み） ・自動修正案の提示と適用
・GitHub PR上での対話的な修正が可能
・IDE連携により、実装段階で脆弱性を排除できる		 ・AWS環境全体の脆弱性ステータスを一元管理可能
・SBOM出力など、組織的なガバナンス対応に強い
概算コスト $19 / ユーザー / 月
（開発者数に応じた月額定額制）		 $0.50 / スキャン
（リポジトリ・スキャンごとの従量課金）
導入の容易さ ◎（GitHubアプリ連携のみ） ◎（MasterのみのスキャンであればAWSコンソールからの連携可）
主なユースケース ・新規機能の実装中に、セキュアなコードをAIに生成させる
・コードレビューを自動化し、PRの修正ループを高速化したい
・既存コードのバグ修正やリファクタリングをAIに依頼したい		 ・本番環境にデプロイされる全コードの脆弱性を網羅的にチェックしたい
・組織のセキュリティ基準（PCI DSS等）への適合性を証明したい

先に結論（選定のアドバイス）

  • Q Developer は、SASTに加えてAIエージェントなので、実装中に修正コードまで提案・生成するため「開発者の修正工数を減らしたい場合」にも役立ちます。
  • Inspector Code Security は、コミット時に実行される静的なSASTであり、都度（リアルタイム）やフューチャーブランチで使わないが、マージ前には必ず通したいといった運用や、すでに他のAIエージェントを利用しているチーム、大規模組織でのコスト最適化に適しています。

我々のチームでは

  • すでにAIエージェントは別のものを利用していること
  • 価格が安価で一元管理しやすいこと

から、Inspector Code Securityを選択しました。

各導入方法について

Q DeveloperはGithubへのシームレスな統合が可能で、Github側にアプリインストールさえすれば、自動でプルリクエストを検査してくれるようになります。

一方で、inspector code securityは、CICDパイプラインへ組み込むことで、デプロイフェーズで検査することが一般的な使い方です。

Q developerの導入方法

  1. Kiroのサービスページに遷移して、GitHub での Amazon Q Developerタブをクリック
    Qdev_1.png

  2. 先に開始方法にあるGitHub マーケットプレイスから Amazon Q Developer アプリ のインストールを行っておく。（後工程で接続するため）
    Qdev_2.png

    このときにすべてのリポジトリを検査するか、一部のリポジトリに絞るかの選択ができます。

  3. Kiroのサービスページに戻り、インストールを登録をクリック

  4. 認可をクリック（すでにGithubアカウントにログインしている状態であれば、ログインなしでアクセス許可がされる）
    Qdev_3.png
    Qdev_4.png

  5. そのまま「登録」をクリックし、登録完了

    Qdev_5.png

やってみた（Q DeveloperによるSAST）

検出してもらうために、以下の脆弱性を埋め込み、変更をプッシュすると

// 🚨 ハードコードされた認証情報 (Secrets Detection)
const AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"; 

// 🚨 ログへの機密情報の出力 (Improper Logging)
console.log("Sending message with API Key " + AWS_ACCESS_KEY_ID + ": ", message);

// 🚨 クロスサイトスクリプティング (XSS)![Qdev_9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2956558/fde07cc5-bf7a-4dac-a64d-cabf09d9f077.png)

<strong>ユーザー:</strong> 
span dangerouslySetInnerHTML={{ __html: msg }} />

Q Developerのアイコンが勝手にあらわれて、検査してる
Qdev_7.png

それぞれの脆弱性を検出して、修正方針もガイド。
🚨 ハードコードされた認証情報 (Secrets Detection)
Qdev_8-1.png
🚨 ログへの機密情報の出力 (Improper Logging)
Qdev_8-2.png
🚨 クロスサイトスクリプティング (XSS)
Qdev_8-3.png

提案を受け入れてみると、自動的にマージを行い、再検査を実行。
Qdev_9.png

Inspector Code Securityの導入方法

  1. Inspectorのサービスページでコードセキュリティタブをクリック
    inspector_1.png

  2. 接続先を選択し、構成スキャンを作成
    inspector_2.png
    （個人的にCodeCommitが表示されないあたり、AWSのサービス撤退の美学を感じる笑）
    inspector_3.png

  3. Githubへの認証リンクを踏んで承認
    inspector_4.png
    inspector_5.png

  4. 再度AWSコンソールに戻り、新しいアプリをインストールする
    inspector_6.png

  5. 再びGithubに遷移し、Q developerと同じようにすべてのリポジトリか、一部かを選択inspector_7.png

  6. しばらくすると全リポジトリがAWS上に表示inspector_9.png

  7. スキャン頻度は推奨を選択。（デフォルトだと推奨になっていない&推奨にするとコスト上がるので注意）
    inspector_8.png

やってみた（Inspector Code Security）

実際に動かしてみると、以下のようなビューで確認可能。

inspector_10.png

個人的に

  • どのファイルの何行目かまで明示的に展開してくれるのでよいが、ファイルパスはハイパーリンクではないのが手間
  • 安価で勝手にスキャンを実行してくれるのは魅力的だが、以下のちょっと挑戦のようなことをしなければMaster以外のスキャンができないのが手間

という感想なので、今後のアプデに期待です！

ちょっと挑戦

Inspector Code Securityの場合、スキャンするリポジトリは選択できますが、ブランチはデフォルトでMasterとなっていて変更ができません。

当初フューチャーブランチでの検査を行うことで、早期の脆弱性発見を行いたいと考えていたこともあり、この障壁の打破に挑戦してみました。

ググったところ、どうやらInspectorの機能自体はツール化されているようなので、GithubActionsのWorkFlowの中に組み込むことで、ワークフロー内で脆弱性を検出してくれるようです。

  1. .github/workflow/inspector-scan.ymlを作成し、Github内に配置

    name: Amazon Inspector Code Scan

on:
  # マージ先が testのプルリクエストが作成された時に実行
  pull_request:
    branches:
      - test
  # 手動実行用
  workflow_dispatch:

permissions:
  id-token: write
  contents: read
  security-events: write # GitHub Securityタブへの書き込みに必須

jobs:
　# 以下ツール部分
  inspector-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ap-northeast-1

      - name: Amazon Inspector Code Scan
        uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
        with:
          artifact_type: 'repository'
          artifact_path: './'
          display_vulnerability_findings: 'true'
          output_format: 'sarif'

      - name: Upload scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'vulnerability-scan-results.sarif'

    重要なのが

    • branches
    • AWS_ROLE_ARN

    です。※それ以外は基本流用可。

    branches =プルリク時に検査したい対象ブランチ
    AWS_ROLE_ARN ＝ STSを使って一時的な認証情報を作成ためのIAMロール

  2. AWS側ではCloudFormationを利用で、以下のスタックを作成します。

    AWSTemplateFormatVersion: '2010-09-09'
Description: IAM Role for GitHub Actions to scan with Amazon Inspector

Parameters:
  GitHubOrg:
    Type: String
    Description: GitHubの組織名（またはユーザー名）
  OIDCAudience:
    Type: String
    Default: "sts.amazonaws.com"

Resources:
  # 1. GitHub用のOIDCプロバイダー（既に存在する場合は既存のものを利用）
  GitHubOIDCProvider:
    Type: AWS::IAM::OIDCProvider
    Properties:
      Url: https://token.actions.githubusercontent.com
      ClientIdList:
        - !Ref OIDCAudience
      ThumbprintList:
        - fingerPrintXXXXXXXXXXXXXXXX # GitHubのfingerprint

  # 2. Inspector実行用ロール
  InspectorScanRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: GitHubActionsInspectorRole
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Action: sts:AssumeRoleWithWebIdentity
            Principal:
              Federated: !Ref GitHubOIDCProvider
            Condition:
              StringLike:
                # 指定したリポジトリの全ブランチからのアクセスを許可。リポジトリ単位の制御も可能。
                token.actions.githubusercontent.com:sub: !Sub "repo:${GitHubOrg}/*"
              StringEquals:
                token.actions.githubusercontent.com:aud: !Ref OIDCAudience
      Policies:
        - PolicyName: InspectorScanPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  # Inspectorでコードスキャンを実行するために最低限必要な権限
                  - inspector2:ScanSbom
                  - inspector2:ListFindings
                  - inspector2:GetFindingsReportAccountStatus
                Resource: "*"

Outputs:
  RoleArn:
    Description: GitHub Actionsの設定に使用するRole ARN
    Value: !GetAtt InspectorScanRole.Arn

    重要なのが

    • GitHubOrgのOrganization名をGithubアカウントと同じにすること
    • GitHubのfingerprint
    • スキャン対象のリポジトリ・ブランチを指定する

    です。※それ以外は基本流用可。

  3. 2で作成したIAMのARNをGithubのシークレットに保存し、プルリク実行するとQ developerと同様にプルリク時にInspector Code Securityが動作！
    inspector_11.png

  • Github上で可視化したい場合は、Github Securityを有効化すれば可能。※無料のGithubでは不可；；
  • 有料版のGithubを使わない限りは、脆弱性がログ出力されるのみなので、脆弱性管理としてはGithub Securityの利用が必須。
3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?