コードを多く書くほど、アプリケーションの安全性は低下する。
なぜ？一言で言えば、複雑さだ。
現代のアプリケーションはゼロから書かれるわけではない。組み立てられるのだ。開発者はオープンソースのフレームワーク、ライブラリ、コンテナイメージ、クラウドサービスの上にカスタムロジックを記述する。つまり、セキュリティ脆弱性は二つの全く異なる方法で導入される可能性がある：
- あなたが書くコードを通じて、そして
- あなたが依存するコードを通じて。
OWASPトップ10によると、最も一般的な脆弱性のカテゴリー（SQLインジェクション、クロスサイトスクリプティング、アクセス制御の不備、不安全な設計）は、コーディングとロジックの欠陥に起因している。
これがSAST（静的アプリケーションセキュリティテスト）とSCA（ソフトウェア構成分析）が重要であり、混乱が生じる理由です。SASTとSCAはどちらも自社開発コードのリスク低減手法ですが、異なるアプローチで異なる問題を解決します。
本記事では、SASTとSCAの役割を解き明かし、各セキュリティテストツールが最も重要となる場面、そして現代のアプリケーションセキュリティチームが開発を遅滞なく進めつつ両者を組み合わせる方法について解説します。
TL;DR
要約すると：
- SASTは、記述したコード内のセキュリティ上の問題（ロジックの欠陥、インジェクション、バッファオーバーフロー）を検出します。
- SCAは、依存しているコード内のセキュリティ問題（オープンソースの脆弱性、ライセンス、サプライチェーンリスク）を検出します。
- これらはどちらも安全なソフトウェア開発ライフサイクル（SDLC）にとって不可欠です。単に、異なるリスク要因によって生じる異なる問題を解決するだけです。
- 一方のみを使用すると、アプリケーションに死角が生じます。セキュリティを意識したチームは両方を活用し、迅速な開発と本番環境での問題修正コスト削減を実現します。
SASTとSCA：主な相違点
静的アプリケーションセキュリティテスト（SAST）とは何ですか？
SASTは、安全でないコードに対する最初の防御ラインです。これは、ソフトウェア開発ライフサイクル（SDLC）の初期段階で脆弱性やセキュリティ上の欠陥を特定するために、アプリケーションのソースコード、バイトコード、またはバイナリコードを分析する手法です。
SASTが検出できる脆弱性の種類は多岐にわたり、検出可能な範囲は、採用しているコーディング手法、技術スタック、およびフレームワークによって異なります。
以下は、SASTがコード内で検出する脆弱性の3つの例です。
脆弱な暗号化手法：以下は、廃止されたMD5ハッシュ関数を使用する脆弱なPython暗号化コードです：
import hashlib
def store_password(password):
# Weak hashing algorithm (MD5 is broken and unsuitable for passwords)
hashed_password = hashlib.md5(password.encode()).hexdigest()
print(f"Storing hashed password: {hashed_password}")
return hashed_password
ソースコード内のハードコードされたシークレット:以下は、ハードコードされたシークレットを含む脆弱なJavaScriptコードです:
import { Client } from "pg";
const client = new Client({
host: "db.internal",
user: "admin",
password: "secret",
database: "app",
});
await client.connect();
リモートコード実行（RCE）脆弱性：攻撃者がJavaScriptのeval()関数を用いて任意のコードを実行する能力を与える。
eval(ユーザー入力);
一本の線。一つの脆弱性。一つの危険信号！
他にも数多くの事例をご紹介できます。SASTツールを活用することで貴重な知見が得られ、問題が深刻化する前に修正することが可能になります。
SASTの主な機能
SASTツールが備えるべき基本的な機能と能力があります。ツールがこれらを提供できない場合、チームの助けになるどころか、棚上げされるか、チームの作業を遅らせる結果となる可能性が高いです。
- 幅広い言語とフレームワークのサポート： のSASTツールは 、単一のフレームワークだけでなく、コードベース全体で動作する必要があります。現代のエンジニアリングチームは、複数の言語環境で作業したり、モノレポジトリに依存したりすることが多いです。SASTスキャナーが様々な言語やフレームワークをサポートしていない場合、アプリケーションセキュリティプログラム全体を損なうギャップが生じます。参考として、SASTツールの基本的な要件についてはOWASPのアプリケーションセキュリティ検証基準（ASVS）を参照してください。
- 実行を伴わないソースレベル（またはバイトコードレベル）の解析： のSASTは 、プロプライエタリなコードを実行せずに解析すべきです。これが「静的」の意味です。また、コードを記述する際にリアルタイムの洞察を提供すべきです。SASTの仕組みの詳細については、この究極のSASTガイドをお読みください。
- データフロー、制御フロー、および汚染分析：まずSASTはアプリケーション内でのデータ移動を把握し、次に既知の問題（不安全なパターンから汚染伝播まで）に対する事前定義ルールを用いて、コード全体にわたる潜在的な脆弱性をフラグ付けします。
- 開発者ワークフロー（IDE、CI/CD、バージョン管理）との統合： Travis CIを好むチームもあれば 、Jenkins を支持するチームもあります。幅広い言語やフレームワークのサポートと同様に、さまざまな開発ワークフローのサポートも非常に重要です。Aikido ソリューションのような SAST ツールは、100 以上の開発ツールとの統合に加え、IDE および PR コメントでのインラインフィードバック、CI/CD パイプラインでのゲーティング機能を提供します。
- 偽陽性率が低く、意味のある優先順位付け： おそらくこんな話を聞いたことがあるでしょう ：「SASTを試したけど、ノイズが多すぎて、問題ではない箇所の追跡に時間を費やしてしまった」
誤検知は普及を阻害する。
SASTは正確で文脈を認識した到達可能性分析を備え、スタイルに関する意見ではなく、実際の脆弱性を明らかにするように設計されるべきである。
- 明確で実行可能な修正ガイダンス：脆弱性の発見は SASTツールの役割の半分に過ぎません。開発者は何が問題で、どう修正すべきかを理解する必要があります。優れた修正ガイダンス（実践的で理解しやすく、現実世界のベストプラクティスに基づいているべきもの）に加え、AI生成の修正は今日のSASTにおける画期的な進化です。選択すべきSASTツールは、即座にコード修正の提案（信頼度レベル付き）を提供すべきです。
- コンプライアンスとセキュアコーディングの徹底を強化：コードの 非準拠は製品の成否を左右します。SASTはOWASP Top-10やCWE/CERTポリシーなどの基準違反を検知し、規制要件の達成を支援すべきです。さらに優れた選択肢は、コンプライアンススイートと直接連携可能なツールを選ぶことです。
- 高速なパフォーマンスとスケーラビリティ： 拡張時にボトルネックとなるSASTツールは避けるべきです 。コードベースが拡大するにつれ、スキャナはそれに比例して拡張し、エンジニアの作業を妨げてはなりません。
SASTの利点
- SDLCの初期段階で脆弱性を検出（シフトレフト）：SAST （ ）により、組織は低コストで脆弱性を早期に捕捉し、セキュリティ対策の「シフトレフト」を実現できます。
- 時間の経過とともにセキュアコーディングの実践を向上させます： SASTは継続的に不安全なパターンを指摘し、より安全な代替案を推奨することで 、チーム全体のセキュリティ基準を引き上げ、開発者がデフォルトで安全な習慣を身につけるのを支援します。
- 自動化とAI支援型修正機能をサポート：現代のSASTツールは修正案を自動提案するため、手作業を削減し修正プロセスを加速します。
- コンプライアンス：前述の通り 、コンプライアンスはSASTの主要な特徴の一つであり、金融サービスや医療など規制の厳しい業界の組織にとって大きな利点となります。SASTを活用することで、ソースコードレベルでこれらの要件を満たすことが可能です。
SASTの限界
- カバレッジのギャップ：SASTはサードパーティやオープンソースのリスクをカバーせず、実行時や設定の問題も検出できません。SASTだけでは完全なセキュリティを提供できません。
- 誤検知：SASTソリューションの主な制限の一つは、誤検知が発生しやすい点です。そして今日のインフラの複雑さにより、誤検知の数は概して多くなっています。
- 各言語やフレームワークごとに異なるSASTツール：複数のプログラミング言語を使用する組織は、多くの言語をサポートするSASTを見つけるのに苦労します。複数の言語を使用する場合、各SASTインスタンスには異なるメンテナンスと設定プロセスが必要となり、運用コストが積み上がる可能性があります。
ソフトウェア構成分析（SCA）とは何ですか？
SCAはオープンソース依存関係スキャンとしても知られています。SCAテストプロセスでは、アプリケーションを支えるオープンソースコンポーネント内のリスクを特定し管理します。
依存関係を利用する時、大抵は全てが順調だと考えがちだ。しかし現実には、大規模化に伴う混乱は緊急性を伴わなければ管理できない。
この現実を踏まえると、オープンソースのサプライチェーンの構成を理解することは非常に困難です。これが、SCAツールがほとんどの組織のセキュリティプログラムにおいて不可欠な要素となっている理由です。
では、SCAテストではどのような脆弱性を発見できるのでしょうか？
以下は、SCAテストがコード内で検出する脆弱性の3つの例です。
Vulnerable open-source dependency (known CVE): The following example is a vulnerability because lodash < 4.17.21 is affected by multiple prototype pollution vulnerabilities.
{
"dependencies": {
"lodash": "4.17.15"
}
}
使用方法によっては、サービス拒否や任意のコード実行を引き起こす可能性があります。
脆弱なコンテナベースイメージ：SCAテストは、インストール済みパッケージを既知のCVEデータベースと照合し、継承されたセキュリティ欠陥をフラグ付けすることで、脆弱なベースイメージを特定できます。例えば、パッチ未適用のUbuntu 24.04ベースイメージをスキャンすると、システムライブラリにおけるCVE-2025-9900のような重大な脆弱性が検出される可能性があります。この脆弱性は、そのイメージを基に構築された全てのコンテナに継承される可能性があります。
ライセンス準拠違反：依存関係が商用配布と競合する可能性のある制限的なライセンス（例：GPL）を使用している場合。SCAは以下を検出します：
- ライセンスの種類
- ポリシー違反
- 再配布のリスクレベル
SCAの主な特徴
SCAテストツールが備えるべき基本的な機能と能力があります。以下にその5つを示します：
- 直接依存関係と間接依存関係の両方のオープンソースコンポーネントを特定します：SCAツールは ソースコード、パッケージマネージャー、バイナリ、CI/CDパイプライン、コンテナを含むコードリポジトリ全体をスキャンし、明示的に宣言された依存関係だけでなく、間接的に（継承された）含まれる依存関係も検出します。この可視性は極めて重要です。なぜなら、オープンソースコンポーネントの脆弱性の95%は間接依存関係に起因するからです。
- ソフトウェア部品表（SBOM）の生成： SCAを使用して作成できます すべてのオープンソースコンポーネントのインベントリ with:
- コンポーネント名、バージョン、場所、サプライヤー/メンテナンス業者
- 関連するオープンソースライセンス。
さらに一歩進んで依存関係を可視化することで、分析の精度向上や潜在的な脆弱性/競合の特定が可能となります。
- 脆弱性評価：SCAは SBOMを、NVD（National Vulnerability Database）、CVE、GitHub Advisory、Aikido などの既知の脆弱性データベースと比較できます。Aikido のような定期的に更新されるデータベースは、新たな脆弱性をリアルタイムで検知し、攻撃対象領域を縮小します。
- オープンソースライセンスの遵守: SCAは 各依存関係に対するライセンス条項を特定する。例：
- GPLライセンス：制限的、変更内容の共有を要求する
- MITライセンス：ほぼ完全な自由を認める、非常に寛容なオープンソースソフトウェアライセンス。
- BSLライセンス：公開コードだが使用制限あり。
合気道のようなSCA Aikidoと同様に、ライセンスの競合、制限、または内部組織ポリシー違反をフラグ付けします。
- 脆弱性対策と自動トリアージ：現代的なSCAは リスクを発見するだけでなく、AIを活用した対策と自動修正を提供します。例えば、Aikido を使用すれば、プロジェクト内のサードパーティ依存関係における脆弱性を修正できます。
Aikido 、パッケージの更新やその他の手段で脆弱性を除去するプルリクエストを作成することでこれを実現します。場合によっては、単一の課題ではなく、脆弱性のクラス全体を除去できるAikido 。
継続的監視と報告：SCAは 定期的にコードベースを再スキャンし、新たな脆弱性を検出するとともにSBOMを更新します。これにより、OSコンポーネント、そのバージョン、および関連するリスクに対するリアルタイムの可視性が維持されます。
SCAの利点
- 自動化：オープンソースコードの脆弱性を手動で特定することは不可能です。SCAは、開発チームが脆弱性をもたらすコードを記述するのと同時に、オープンソースコンポーネント内の既知のセキュリティ脆弱性を追跡・特定します。統合後は、開発者の最小限の労力でSCAが継続的に稼働します。
- サプライチェーン攻撃への曝露を低減：多くの 重大なセキュリティ侵害は依存関係に起因します。SCAは脆弱なコンポーネントや侵害されたコンポーネントをリリース前に検出するのに役立ちます。
- ライセンスコンプライアンスとガバナンス：商業的または規制上の要件と矛盾するライセンスの誤った使用を防止します。
SCAの限界
- 到達可能性コンテキストのないノイズ：SASTと同様に 、SCAも 誤検知に悩まされる。脆弱な依存関係は実際には使用されていないか、影響を及ぼさない可能性がある。SCAの結果を手動でレビューすることは不可能であり、仮に試みた場合、真のリスク評価に充てられたはずの膨大なリソースを浪費する恐れがある。到達可能性分析なしでは、結果がチームを圧倒しかねない。
- カバレッジの不足（ゼロデイの欠如）：SCAは 公開データベースに依存しています。ゼロデイ脆弱性や未知の欠陥を検出できません。ゼロデイ対策には、 Aikido Zenなどのランタイムアプリケーション自己Zen 。Zen OWASPトップ10やゼロデイ脅威を自動防御Zen 、細粒度レベルでのトラフィック遮断により情報漏洩を防止Zen 。
- 修正はしばしば第三者に依存する：オープンソースコンポーネントの脆弱性への対応には、上流のメンテナがパッチをリリースするのを待つ必要がある場合がある。
SASTおよびSCAのユースケース
SASTが適切なツールである場合
SASTを使用するべき場合：
- 不安全なコーディングパターンを早期に発見する
- 論理的欠陥とSQLインジェクションを防止する
- セキュアコーディング基準を徹底する
- 開発段階でのセキュリティ対策の早期導入
- 高コストな生産修正を削減する
SCAが適切なツールである場合
以下の場合にSCAを使用してください：
- オープンソースおよび依存関係のリスクを管理する。
- 脆弱なパッケージやライブラリを検出する。
- ライセンスポリシーを適用する。
- サプライチェーンのセキュリティリスクを低減する。
- ソフトウェア部品表（SBOM）を作成する。
- 出荷内容の可視性を高める。
両方必要な時
以下の場合には、SASTとSCAの両方が必要です：
- あなたは現代的なアプリケーションをリリースします（これはほぼ常に当てはまります）。
- カスタムコードと依存関係全体にわたる完全なカバレッジを求めます。
- あなたは単なる形式的なチェックではなく、現実世界のリスク削減を重視しています。
SASTとSCAを組み合わせた効果的なアプリケーションセキュリティ
SASTとSCAは異なる問題を解決しますが、どちらも強固なアプリケーションセキュリティ態勢に不可欠です。そして、まさにその理由から、両者を併用することで最大の効果を発揮します。
SASTとSCAセキュリティテストツールを組み合わせた多層的なアプローチにより、チームは以下のことが可能になります：
- 脆弱性を早期に発見する
- より良い文脈と優先順位付けによるノイズの削減
- 開発者の生産性を維持する
- リリース速度を落とさずに生産リスクを最小化する
高度なアプリケーションセキュリティスイートであるAikido 、この統合を実現します。脆弱性管理から継続的なコンプライアンス可視化まで、Aikido 最初のコミットから本番環境までコードをAikido 。
Aikido 見てみませんか？リポジトリをスキャンする登録をすれば、2分以内に最初のSCAとSASTの結果が得られます。
よくある質問
SASTとSCAは併用できますか？
はい。そして、そうあるべきです。
SASTとSCAは異なる問題を解決します：
- SASTは、あなたが書いたコード内の脆弱性を検出します
- SCAは、依存しているコードに脆弱性を発見します
一方のみを使用すると死角が生じる。現代のアプリケーションセキュリティチームは、開発速度を落とさずにアプリケーションスタック全体をカバーするため、両方を継続的に運用している。
SASTはどのような種類の脆弱性を検出しますか？
SASTはコーディングおよびロジック設計中に導入された脆弱性を検出します。これには以下が含まれます：
- インジェクション脆弱性（SQLインジェクション、コマンドインジェクション、コードインジェクション）
- 破損した認証とアクセス制御
- 不適切な暗号化の使用
- ハードコードされたシークレット
- 安全でないデータフロー
- ビジネスロジックエラー
これらは最も一般的なOWASP Top 10カテゴリにほぼ対応しています。
最高のSASTツールは、AIを活用したトリアージ機能も提供し、真のリスクを優先順位付けし、誤検知を排除し、修復措置を実施します。
SASTツールはソースコードをどのように分析しますか？
SASTツールはコードを実行せずに分析します。
彼らは以下のような技術を使用します：
- パターンおよびルールに基づく分析。
- データフローグラフと制御フロー解析。
- 入力から危険なシンクまでの汚染追跡
- フレームワークとAPIの意味論的理解。
これにより、SASTはコードがリアルタイムで記述されている段階で問題を早期に検出できます。
SAST、DAST、SCA、IASTの違いは何ですか？
- SAST（静的アプリケーションセキュリティテスト）：実行前にソースコードを分析し脆弱性を検出する。
- DAST（動的アプリケーションセキュリティテスト）： 実行中のアプリケーションを外部からテストし 、実行時の問題を発見する。
- SCA（ソフトウェア構成分析）： サードパーティ製依存関係について既知の脆弱性とライセンスリスクをスキャンします 。
- IAST（インタラクティブ・アプリケーション・セキュリティ・テスト）： 計測ツールを用いて、実行時のアプリケーション動作を観察する 。
各手法は異なるリスク領域をカバーする。単独では不十分である。
今すぐソフトウェアを保護しましょう
.avif)
