運用環境で発見されたソフトウェアの脆弱性を修正するには、開発段階で発見された脆弱性の修正に比べて、平均で4倍のコストがかかります。IBMの2025年版「データ侵害コストレポート」によると、侵害の平均コストは4.88万ドルで、検出されなかったソースコードの脆弱性に起因する侵害は、根本原因の修復にインシデント対応だけでなくコードベースの修復も必要となるため、最もコストのかかるケースの一つです。コードスキャンツールは、脆弱性の発見を侵害後ではなく、開発環境のできるだけ早い段階で行うために存在します。
コードスキャンとは、ソフトウェアが本番環境に投入される前に、ソースコード、コンパイル済みバイナリ、または実行中のアプリケーションを自動的に分析し、セキュリティ脆弱性、品質上の欠陥、コンプライアンス違反、および技術的負債を特定することです。これはアプリケーションセキュリティの基盤となるレイヤーであり、侵入テストや脅威モデリングの代替となるものではありませんが、大規模な環境では人間のレビュー担当者が一貫して検出できない、予測可能で再現性のある種類のエラーを捕捉する体系的なベースラインとなります。
チームが出荷するすべての言語をスキャンしてください
SMART TS XL COBOL、Java、Python、JavaScript、そしてお客様のポートフォリオ全体に対して、静的コードスキャンを同時に実行します。
さらに詳しく…コードスキャンとは何ですか？
コードスキャンとは、ソフトウェア成果物（ソースコード、バイトコード、バイナリ、実行中のアプリケーションなど）を自動的に検査し、すべての行を人間が手動で確認することなく欠陥を特定する手法です。スキャンツールは、ルールセット、パターンマッチング、データフロー分析、そしてより高度なツールではプロシージャ間汚染追跡などを適用し、そうでなければ本番環境にまで到達してしまうような問題を検出します。
コードスキャンとは何か：コードレビュー、アーキテクチャ分析、侵入テスト、ランタイムモニタリングの代替となるものではありません。コードスキャンは、コードレビュー担当者がルーチン作業のように見えるために注意深く確認しない部分も含め、コードベース全体にわたって既知のパターンを確実かつ一貫して検出する、高速で体系的かつ拡張性の高い最初のフィルターです。
この文脈におけるコード検証とは、コードが仕様どおりに動作していることを確認することです。スキャンは検証の構成要素の一つであり、パターン検出とデータフロー分析を処理する自動化された要素です。手動レビュー、テスト、形式検証はその他の構成要素です。これらが組み合わさって検証プログラムを構成します。スキャンだけでは不十分です。
静的コードスキャンと動的コードスキャン：その核心的な違い
スキャンプログラムを構築する上で最も重要な選択は、各手法がいつ実行され、何を見ることができるのかを理解することです。
| 次元 | 静的（SAST） | ダイナミック（DAST） |
|---|---|---|
| 実行時 | ソースコード上では、実行は不要です。 | 実行中のアプリケーションに対して |
| 何が見えるか | コード構造、データフロー、パターン違反 | 実行時動作、サーバー構成、API応答 |
| 発見 | SQLインジェクションパターン、ハードコードされた秘密情報、安全でない暗号化、コードの臭い | 認証バイパス、ランタイムインジェクション、セッション管理の欠陥、サーバー設定ミス |
| ミス | 実行時のみの脆弱性、設定の問題 | テスト中にトリガーされないコードレベルのパターン |
| 速度 | 速く、数秒から数分で完了します。 | 動作が遅く、実行環境が必要です |
| 開発者からのフィードバック | 即時、IDE、または事前コミット | 遅延しています。アプリケーションのデプロイが必要です。 |
| 偽陽性率 | より高い、実行時コンテキストが欠落している | 低い値、悪用可能性を確認 |
| 最適な統合 | IDE、プリコミット、すべてのプルリクエストに対するCI/CD | ステージング環境、プレリリースゲート |
ほとんどのチームにとって現実的な解決策は、両方を実行することです。IDEとCIパイプラインでの静的スキャンは、コードパターンに関する迅速かつ早期のフィードバックを提供します。ステージング環境に対する動的スキャンは、脆弱性の可能性を確認し、静的解析では検出できない構成上の問題を検出します。
コードスキャンの4つのタイプ
SAST（静的アプリケーションセキュリティテスト）
SASTは、実行せずにソースコード、バイトコード、またはバイナリを分析します。これは最も一般的なコードスキャン手法であり、IDEやCI/CDパイプラインに統合されています。SASTは、汚染分析（信頼できない入力から危険なシンクまでを追跡）によるインジェクション脆弱性、パターンマッチングによる暗号化の悪用、文字列分析によるハードコードされた認証情報、およびメトリクスとパターンルールによる構造的な品質問題を検出します。
最適なツール: Semgrep、SonarQube、Checkmarx、CodeQL、Veracode、Snyk Code、 SMART TS XL.
DAST（動的アプリケーションセキュリティテスト）
DASTは、稼働中のアプリケーションに対して、細工された入力を送信し、応答を監視することで動作します。ソースコードを見ることはできず、攻撃者と同じように外部からアプリケーションとやり取りします。DASTは、実行時コンテキストを必要とするためSASTでは検出できない認証バイパス、ビジネスロジックの欠陥、サーバーサイドリクエストフォージェリ、構成上の脆弱性などを検出します。
最適なツール： OWASP ZAP、Burp Suite、Invicti、Acunetix、HCL AppScan。
SCA（ソフトウェア構成分析）
SCA は依存関係マニフェストをスキャンします (package.json, pom.xml, requirements.txt, go.mod脆弱性データベースに対してスキャンを実行し、サードパーティライブラリ内の既知のCVEを特定します。現代のアプリケーションはすべてオープンソースの依存関係を使用しています。SCAは、これらの依存関係が既知の脆弱性を引き起こさないことを保証するスキャンレイヤーです。
最適なツール： Snyk、OWASP Dependency-Check、Mend（旧WhiteSource）、GitHub Dependabot、npm audit。
IAST（インタラクティブ・アプリケーション・セキュリティ・テスト）
IASTは、アプリケーションサーバーに組み込まれたエージェントまたはセンサーを使用して、実行時にアプリケーションを計測します。アプリケーション内部から実際の要求処理を監視し、DASTの実行時精度とSASTのコードレベルの洞察力を兼ね備えています。IASTは4つのタイプの中で誤検知率が最も低いですが、計測済みのデプロイメント環境が必要です。
最適なツール： Contrast Security、Seeker（Synopsys）、HCL IAST。
これらを組み合わせる方法：開発者への迅速なフィードバックのために、コミットごとにSASTを実行します。依存関係の変更ごとにSCAを実行します。リリース前にステージング環境に対してDASTを実行します。誤検出率を最小限に抑える必要がある重要なアプリケーションには、IASTを追加します。
コードスキャンで実際に何が見つかるか
スキャンタイプによって検出できる脆弱性の種類が異なります。このマッピングは、各チームがそれぞれのリスクプロファイルに合わせてどのスキャナーに投資すべきかを理解するのに役立ちます。
| 脆弱性カテゴリ | サスト | ダスト | SCA | IAST |
|---|---|---|---|---|
| SQLインジェクション | 強力（汚染分析） | 強力（積極的なテスト） | いいえ | 強い |
| XSS | 穏健派 | 強い | いいえ | 強い |
| ハードコードされた秘密情報／認証情報 | 強力な（パターンマッチング） | いいえ | 一部 | いいえ |
| 壊れた認証 | 部分的な（型紙のみ） | 強い | いいえ | 強い |
| 脆弱な依存関係（CVE） | いいえ | いいえ | 強い | いいえ |
| 暗号技術の悪用 | 強力な（既知の悪質なAPI） | いいえ | 一部 | 一部 |
| セキュリティ設定の誤り | 部分的（コード内の設定） | 強い | いいえ | 一部 |
| SSRF | 強力（汚染分析） | 強い | いいえ | 強い |
| パストラバーサル | 強い | 穏健派 | いいえ | 強い |
| コマンドインジェクション | 強力（汚染分析） | 強い | いいえ | 強い |
| コード品質／技術的負債 | 強い | いいえ | いいえ | いいえ |
| デッドコード | 強い | いいえ | いいえ | いいえ |
SDLCにおけるコードスキャン：いつ何を実行するべきか
セキュリティにおける「シフトレフト」の原則、つまり脆弱性の検出を開発ライフサイクルのできるだけ早い段階で行うという原則こそが、コードスキャンが標準的な手法となった理由です。開発者のIDEでSQLインジェクションを発見すれば、修正にかかる時間はわずか数分です。しかし、侵害が発生した後に本番環境で発見した場合、インシデント対応、修復、規制報告に数週間もの時間を要します。
IDEでは、 SonarLint、Snyk IDE拡張機能、Semgrep IDEプラグインなどが、開発者がコードを記述する際にインラインで脆弱性を検出します。脆弱性のある行が記述された際に表示されるSQLインジェクションの警告は、修正に数秒しかかかりません。
プリコミットフック：コードがリポジトリに到達する前に、高速なSASTルールとシークレット検出を実行します。プリコミットフックは10秒以内に完了する高速なものでなければならず、そうでなければ開発者が無効にしてしまうでしょう。
すべてのプルリクエストに対して、完全なSASTスキャンとSCAチェックを実施します。多くのチームはここで品質ゲートを適用し、新たな重大な問題が発見された場合はマージをブロックします。
毎晩または毎週：詳細なプロセス間分析、完全なDASTスキャン、包括的なSCA監査。これらはコミットごとに実行するには時間がかかりすぎるが、メインブランチで定期的に実行される。
完全なCI/CDスキャン構成：
ヤムル
# GitHub Actions: layered scanning at the right pipeline stage
name: Code Scanning Pipeline
on:
push:
branches: [main, develop]
pull_request:
jobs:
sast:
name: Static Analysis
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST scan
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/security-audit
p/secrets
- name: SonarCloud quality gate
uses: SonarSource/sonarcloud-github-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
sca:
name: Dependency Scan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Snyk dependency check
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high
secrets:
name: Secret Detection
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: TruffleHog secret scan
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verifiedコードスキャンツール：実践的な概要
| ツール | タイプ | 以下のためにベスト | オープンソース |
|---|---|---|---|
| セムグレップ | サスト | カスタムルール、高速スキャン、多言語対応 | はい（コミュニティルール） |
| SonarQube / SonarCloud | サスト | 品質＋セキュリティ、CI/CD統合、トレンド追跡 | コミュニティエディション |
| コードQL | サスト | 深い意味解析、GitHubネイティブ | はい |
| チェックマーク | サスト | エンタープライズアプリケーションセキュリティプログラム、コンプライアンス | いいえ |
| スニックコード | サスト | 開発者に優しい、IDE優先のセキュリティ | フリーミアム |
| OWASP ザップ | ダスト | 無料のDAST、CI/CD互換 | はい |
| げっぷスイート | ダスト | 手動および自動化されたWebアプリケーションセキュリティテスト | コミュニティエディション |
| スニック / メンド | SCA | 依存関係の脆弱性管理 | フリーミアム |
| OWASP 依存関係チェック | SCA | オープンソースの依存関係に関するCVEスキャン | はい |
| コントラストセキュリティ | IAST | 実行時の精度が高く、誤検出が少ない。 | いいえ |
| SMART TS XL | SAST + 構造 | 多言語、COBOL、エンタープライズ、レガシー | いいえ |
効果的なコードスキャンのベストプラクティス
信頼性が高く、ノイズの少ないルールから始めましょう。初日から利用可能なすべてのルールセットを実行すると、何千もの検出結果が出て開発者を圧倒し、導入を阻害します。まずは、重要度が高く信頼性の高いルール、OWASP Top 10パターン、秘密の検出、既知の危険な関数呼び出しなど、厳選されたルールセットから始めましょう。チームがツールへの信頼を深めるにつれて、ルールを段階的に追加していきます。
新規コードのみに適用します。既存の不具合が残っているレガシーコードベースの場合、品質ゲートを設定して、現在のプルリクエストで導入された不具合のみをブロックするようにすることで（コードベース全体をブロックするのではなく）、既存の不具合のバックログを作成して開発全体をブロックすることなく、セキュリティチェックをワークフローに組み込むことができます。
ヤムル
# SonarQube: new-code quality gate configuration
# Block merges on new critical security hotspots only
sonar.qualitygate.wait=true
sonar.newCode.referenceBranch=main
# Existing findings in main don't block PRs
# Only new findings in the PR diff are gated誤検出を体系的に調整しましょう。開発者が一度調査して無視する誤検出は迷惑なだけです。しかし、6か月間すべてのプルリクエストで誤検出が発生すると、開発者は検出結果を完全に無視するようになります。抑制レビュープロセスを確立しましょう。すべての抑制には文書化された正当性が必要であり、抑制は四半期ごとにレビューされます。
調査結果を深刻度レベルにマッピングします。すべての調査結果に即時対応が必要なわけではありません。段階的な対応：
- クリティカル （CVSS 9以上、悪用可能と確認済み）：展開をブロックし、24時間以内に修正する。
- ハイ (CVSS 7-8): PRマージをブロックし、スプリント内で修正する
- 技法バックログに追加し、四半期内に対応します。
- 低レベル／情報提供レベル: リファクタリング中に追跡、対処する
重要な指標を測定しましょう。深刻度レベル別の平均修復時間（MTTR）、スプリントごとの検出結果と解決済み検出結果の比率、および経時的な誤検出率を追跡します。これらの指標は、スキャナーが稼働しているかどうかだけでなく、スキャンプログラムが正しく機能しているかどうかを示します。
コードスキャンが技術的負債を防ぐ方法
技術的負債は、品質問題が先送りされると蓄積されます。例えば、開発段階でSASTルールによって検出できたはずのSQLインジェクションパターンが本番環境にまで達し、修正のためにセキュリティパッチの適用、回帰テスト、デプロイメントの調整が必要になる場合などです。コードスキャンツールは、この蓄積を発生源で阻止します。
コードスキャンと技術的負債削減を直接結びつける3つのメカニズム：
複雑性の検出。閾値を超える循環的複雑性、深くネストされた条件分岐、長い関数などは、スキャンツールが警告するコードの悪臭です。これらのパターンを放置すると、コードベースは次第に変更が困難かつ高コストになります。スキャンは、複雑性が構造的なものになる前にリファクタリングを促す、メトリクスに基づいた早期警告を提供します。
重複検出。コードの重複は、最もコストのかかる技術的負債の一つです。バグ修正や機能変更は複数の箇所に適用する必要があり、コピーは必然的に乖離していきます。SonarQubeの重複検出機能や同様のルールは、コードベース全体でこのパターンを明らかにし、乖離によって不整合が生じる前に統合を可能にします。
デッドコードの特定。デッドコードとは、本番環境で実行される際に呼び出されることのない関数やモジュールのことで、コードベースのサイズを肥大化させ、開発者を混乱させ、移行分析を複雑化させます。到達可能性分析を実行するスキャンツールは、デッドコードを体系的に特定し、蓄積される前に削除することを可能にします。
複合的な効果として、継続的なスキャンを受けるコードベースは、スキャンを受けていない同等のコードベースと比較して、欠陥密度、循環的複雑度、重複率、デッドコード率が低くなります。これらの指標は、機能開発の迅速化、保守コストの削減、および本番環境におけるインシデントリスクの低減に直接つながります。
認定条件 SMART TS XL エンタープライズ規模のコードスキャン機能を提供
標準的なコードスキャンツールは、単一の言語内で動作します。Javaサービス、Pythonパイプライン、COBOLバッチプログラム、JCLジョブストリーム、RPGモジュールなどが共存する企業環境では、それぞれに独自の構成と検出結果ダッシュボードを備えた独自のスキャナが必要となるため、コードスキャンの状況は断片化されてしまいます。
SMART TS XLさん 静的コード分析 COBOL、JCL、Java、Python、RPG、PL/I、SQL、および最新のスタックといった環境内のすべての言語を同時にスキャンし、単一の分析パスでポートフォリオ全体にわたる統一された品質指標、セキュリティ上の検出結果、および構造データを生成します。レガシーメインフレームアプリケーションと最新のクラウドサービスを併用している組織にとって、この言語横断的な対応は、最新のスタックのみをカバーするスキャンプログラムと、システム全体をカバーするスキャンプログラムとの違いを生み出します。
アプリケーション依存関係マッピング機能は、個々のファイルのスキャンにとどまらず、アーキテクチャ分析へと拡張します。どのコンポーネントの結合度が最も高いか、循環依存関係が存在する箇所はどこか、どのプログラムが明示的なAPIではなく暗黙的なファイルインターフェースを介してデータを共有しているかなどを特定します。これらの構造的な発見は、単一ファイルのパターンマッチングツールでは検出できない、アーキテクチャ上のセキュリティと品質の問題です。
影響分析機能により、スキャン結果を大規模に活用することが可能になります。例えば、150ものプログラムが依存する高ファンインコンポーネントに脆弱性が見つかった場合、影響分析によって修復作業の範囲、テストが必要なプログラム、更新が必要な呼び出し元、修正の影響範囲などが明確になります。これにより、脆弱性の発見は単なる問題リストではなく、範囲が明確に定義された構造化された修復プログラムへと変換されます。
エンタープライズ検索機能により、スキャン結果をポートフォリオ全体にわたってクエリできます。特定の安全でないAPIを使用するすべてのプログラム、ハードコードされた認証情報を含むすべてのファイル、複雑さのしきい値を超えるすべてのコンポーネントを、あらゆる言語の組み合わせで記述された数百万行のコードから、数秒で見つけることができます。
管理チーム向け レガシーの近代化 プログラム、 SMART TS XLのスキャンは、移行前の品質基準を提供します。移行範囲から除外されるデッドコード、移行の順序を決定する複雑性の分布、および変換されたコードがクラウドインフラストラクチャにデプロイされる前に修正する必要があるセキュリティ上の問題などが含まれます。
早めにスキャン、継続的にスキャン、すべてをスキャン
セキュリティ脆弱性の修復にかかる平均時間が最も短い組織は、最も積極的な侵入テストプログラムを実施している組織ではありません。そうした組織は、コードレビュー段階、開発者のIDE、プリコミットフック、CI/CDパイプラインにおいて、脆弱性が到達する前に最も多くの脆弱性を検出している組織です。コードスキャンは、それを大規模に実現するための手段です。
スキャンプログラムを構築するということは、リスクプロファイルに合わせてSAST、DAST、SCA、IASTの適切な組み合わせを選択し、開発ライフサイクルの適切な段階でそれらを統合し、カバレッジを犠牲にすることなくノイズを最小限に抑えるように調整し、スキャナーが稼働しているという前提ではなく、プログラムの有効性を継続的に測定することを意味します。スキャナーが稼働しているのは始まりに過ぎず、プログラムが機能することが目標です。
