コードを多く書くほど、アプリケーションのセキュリティは低下します。
なぜでしょうか？一言で言えば、複雑性です。
現代のアプリケーションはゼロから書かれるものではありません。それらは組み立てられます。開発者は、オープンソースのフレームワーク、ライブラリ、コンテナイメージ、およびクラウドサービスの上にカスタムロジックを記述します。これは、セキュリティ脆弱性が2つの非常に異なる方法で導入される可能性があることを意味します。
- 記述するコードを通じて、そして
- 依存するコードを通じて。
OWASP Top 10によると、最も一般的な脆弱性のカテゴリ（SQLインジェクション、クロスサイトスクリプティング、不適切なアクセス制御、安全でない設計）は、コーディングとロジックの欠陥に起因しています。
これが、SAST（静的アプリケーションセキュリティテスト）とSCA（ソフトウェア構成分析）が重要であると同時に、混乱が生じる原因でもあります。SASTとSCAはどちらも、自社で記述するプロプライエタリコードのリスクを低減するための手法ですが、異なるアプローチで異なる問題を解決します。
この記事では、SASTとSCAについて、それぞれのセキュリティテストツールが最も重要となるタイミング、そして現代のAppSecチームが開発速度を落とすことなく両方を組み合わせる方法を詳しく解説します。
要約
まとめ：
- SASTは、記述するコード内のセキュリティ上の問題（ロジックの欠陥、インジェクション、バッファオーバーフローなど）を発見します。
- SCAは、依存するコード内のセキュリティ上の問題（オープンソースの脆弱性、ライセンス、サプライチェーンリスクなど）を発見します。
- これらはどちらも、安全なソフトウェア開発ライフサイクル（SDLC）に不可欠です。それぞれ異なるリスク源によって生じる異なる問題を解決します。
- どちらか一方のみを使用すると、アプリケーションに盲点が生じます。セキュリティ意識の高いチームは、両方を使用して迅速に開発を進め、本番環境での問題修正コストを削減します。
SAST vs. 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(userInput);
1行。1つの脆弱性。1つの危険信号！
他にも多くの例を挙げることができます。SASTツールを使用することで、貴重な洞察が得られ、問題が深刻化する前に修正することが可能になります。
SASTの主な機能
SASTツールが持つべき基本的な機能と能力があります。もしツールがそれらを提供できない場合、それは棚の肥やしになるか、チームを助けるどころか遅らせる可能性が高いです。
- 幅広い言語とフレームワークのサポート：SASTツールはコードベース全体で機能するべきです。1つのフレームワークセットだけでなく、現代のエンジニアリングチームは、ポリグロット環境で作業したり、モノレポに依存したりすることがよくあります。SASTスキャナーがさまざまな言語やフレームワークをサポートしていない場合、アプリケーションセキュリティプログラム全体を損なうギャップが生じます。参照として、あらゆるSASTツールの基本的な期待値については、OWASPのApplication Security Verification Standard（ASVS）を参照してください。
- 実行なしのソースレベル（またはバイトコードレベル）分析: SASTは、独自のコードを実行することなく分析する必要があります。これが「静的」の意味するところです。また、コードを記述する際にリアルタイムの洞察を提供する必要があります。SASTの仕組みの詳細については、この究極のSASTガイドをお読みください。
- データフロー、コントロールフロー、およびテイント解析: まず、SASTはアプリケーション内でのデータの流れを理解し、次に、安全でないパターンからテイント伝播に至る既知の問題に関する事前定義されたルールを使用して、コード全体にわたる潜在的な脆弱性を特定します。
- 開発者ワークフロー（IDE、CI/CD、バージョン管理）との統合: Travis CIを好むチームもあれば、Jenkinsを強く支持するチームもあります。幅広い言語とフレームワークのサポートと同様に、多様な開発ワークフローをサポートすることは非常に重要です。Aikido Securityのソリューションのような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の主要な機能の1つであり、金融サービスやヘルスケアのような高度に規制された業界の組織にとって大きな利点です。SASTを使用することで、ソースコードレベルでこれらの要件を満たすことができます。
SASTの制限事項
- カバレッジのギャップ: SASTはサードパーティやオープンソースのリスクをカバーせず、ランタイムや設定の問題も検出できません。SASTだけでは全体的な
- 誤検知: SASTソリューションの主要な制限の1つは、誤警報が発生しやすいことです。今日のインフラストラクチャの複雑さを考えると、ほとんどの場合、多数の誤検知が発生します。
- 言語やフレームワークごとに異なるSASTツール: 複数のプログラミング言語を使用する組織は、多くの言語をサポートするSASTを見つけるのに苦労します。複数のSASTインスタンスを使用する場合、それぞれ異なるメンテナンスと設定プロセスが必要となり、運用コストが増大する可能性があります。
ソフトウェアコンポジション分析 (SCA) とは何ですか？
SCAはオープンソースの依存関係スキャンとも呼ばれます。SCAテストプロセスには、アプリケーションを動かすオープンソースコンポーネント内のリスクの特定と管理が含まれます。
<strong wg-1="">依存関係</strong>を使用するほとんどの場合、すべてが順調だと考えがちです。しかし実際には、大規模なカオスは、緊急性なしには管理できません。
このような状況において、オープンソースサプライチェーンの構成を理解することは非常に困難です。これが、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つを示します。
- Identifies both direct and transitive open-source components: SCAツールは、ソースコード、パッケージマネージャー、バイナリ、CI/CDパイプライン、コンテナを含むコードリポジトリ全体をスキャンし、明示的に宣言された依存関係だけでなく、推移的に（継承されて）含まれるものも検出します。この可視性は、オープンソースコンポーネントの脆弱性の95%が推移的または間接的な依存関係に起因するため、非常に重要です。
- ソフトウェア部品表（SBOM）の生成： SCAを使用して～を作成できます。 すべてのオープンソースコンポーネントのインベントリ 以下を含む：
- コンポーネント名、バージョン、場所、サプライヤー/メンテナー
- 関連するオープンソースライセンス。
さらに一歩進んで、より良い分析と潜在的な脆弱性/競合の特定のために依存関係を視覚化することも可能です。
- 脆弱性評価: SCAは、SBOMをNVD（National Vulnerability Database）、CVE、GitHub Advisory、およびAikido Intelなどの既知の脆弱性データベースと照合できます。Aikido Intelのように定期的に更新されるデータベースは、新しい脆弱性がリアルタイムでフラグ付けされることを保証し、攻撃対象領域を減らします。
- OSSライセンスコンプライアンス: SCAは 各依存関係のライセンス条項を特定します。例:
- GPLライセンス：制限的で、変更の共有を義務付けます
- MITライセンス：非常に許容度の高いオープンソースソフトウェアライセンスで、ほぼ完全な自由を許可します。
- BSLライセンス：公開されたコードだが使用を制限する。
AikidoのようなSCAは、ライセンスの競合、制限、または内部組織ポリシーへの違反をフラグ付けします。
- 脆弱性の修正と自動トリアージ：最新のSCAは、リスクを発見するだけでなく、AIを活用した修正と自動修正を提供します。例えば、Aikido AutoFixを使用して、プロジェクト内のサードパーティの依存関係における脆弱性を修正できます。
Aikido AutoFixは、パッケージの更新またはその他の方法で脆弱性を排除するプルリクエストを作成することでこれを行います。場合によっては、Aikido AutoFixは単一の問題だけでなく、脆弱性のクラス全体を排除できます。
継続的な監視とレポート: SCAは、出現する脆弱性のためにコードベースを定期的に再スキャンし、SBOMを更新します。これにより、OSコンポーネント、そのバージョン、および関連するリスクに対するリアルタイムの可視性が維持されます。
SCAの利点
- 自動化: オープンソースコードの脆弱性を手動で特定することは不可能です。SCAは、開発チームが脆弱性を導入するコードを記述すると同時に、オープンソースコンポーネントにおける既知のセキュリティ脆弱性を追跡し、特定します。一度統合されると、SCAは開発者の労力を最小限に抑えながら継続的に実行されます。
- サプライチェーン攻撃への露出を軽減: 多くの注目すべきセキュリティ侵害は、依存関係に起因しています。SCAは、リリース前に脆弱なコンポーネントや侵害されたコンポーネントを特定するのに役立ちます。
- ライセンスコンプライアンスとガバナンス: 商業的または規制要件と競合するライセンスの偶発的な使用を防ぎます。
SCAの制限事項
- 到達可能性コンテキストのないノイズ: SASTと同様に、SCAも誤検知が多いという問題があります。脆弱な依存関係が実際には使用されていないか、影響がない場合があります。SCAの結果を手動でレビューすることはできず、もしそう選択すれば、真のリスク評価に費やせたはずの膨大なリソースを浪費する可能性があります。到達可能性分析なしでは、結果がチームを圧倒する可能性があります。
- カバレッジのギャップ（ゼロデイなし）: SCAは公開データベースに依存しています。ゼロデイ脆弱性や未知の欠陥を検出することはできません。ゼロデイに対しては、Aikido Zenのようなランタイムアプリケーション自己保護ツールが必要です。Zenは、OWASP Top 10やゼロデイ脅威を自動操縦で防止できます。また、トラフィックを詳細なレベルでブロックして露出を防ぎます。
- 修正はしばしばサードパーティに依存します: オープンソースコンポーネントの脆弱性の修正には、アップストリームのメンテナーがパッチをリリースするのを待つ必要がある場合があります。
SASTとSCAのユースケース
SASTが適切なツールである場合
SASTは以下の場合に利用します。
- 安全でないコーディングパターンを早期に検出します
- ロジックの欠陥とSQLインジェクションを防ぎます
- 安全なコーディング標準を適用します
- セキュリティを開発の初期段階にシフトします
- コストのかかる本番環境での修正を削減します
SCAが適切なツールである場合
SCAは以下の場合に必要です。
- オープンソースおよび依存関係のリスクを管理します。
- 脆弱なパッケージとライブラリを検出します。
- ライセンスポリシーを適用します。
- サプライチェーンのセキュリティリスクを低減します。
- ソフトウェア部品表 (SBOM) を作成するため。
- 出荷するものの可視性を高めます。
両方が必要な場合
SASTとSCAの両方が必要となるのは、以下のケースです:
- 最新のアプリケーションを出荷しています（これはほとんど常に当てはまります）。
- カスタムコードと依存関係全体を完全にカバーしたい
- 単にチェックボックスを埋めるだけでなく、実世界のリスクを軽減することに関心があります。
効果的なアプリケーションセキュリティのためのSASTとSCAの組み合わせ
SASTとSCAは異なる問題を解決しますが、どちらも堅牢なアプリケーションセキュリティ体制には不可欠です。そのため、これらを併用することで最大の効果を発揮します。
SASTとSCAのセキュリティテストツールを組み合わせた多層的なアプローチにより、チームは以下のことが可能になります：
- 脆弱性をより早期に検出します
- より良いコンテキストと優先順位付けによるノイズの削減
- 開発者のベロシティを維持します
- リリースを遅らせることなく本番環境のリスクを最小限に抑えます
Aikido securityのような高度なAppSecスイートは、この統合を実現するのに役立ちます。脆弱性管理から継続的なコンプライアンスの可視化まで、Aikidoは最初のコミットから本番環境までコードを保護することを可能にします。
Aikidoが実際に動作する様子をご覧になりたいですか？ サインアップしてリポジトリをスキャンし、最初のSCAおよびSASTの結果を2分以内に取得できます。
よくある質問
SASTとSCAは併用できますか？
はい。そして、そうあるべきです。
SASTとSCAは異なる問題を解決します：
- SASTは、記述されたコード内の脆弱性を発見します
- SCAは依存するコード内の脆弱性を発見します
一方のみを使用すると、盲点が生じます。最新のAppSecチームは、開発を遅らせることなく、アプリケーションスタック全体をカバーするために両方を継続的に実行します。
SASTはどのような種類の脆弱性を検出しますか？
SASTは、コーディングおよびロジック設計中に導入された脆弱性を検出します。これには以下が含まれます：
- インジェクションの欠陥（SQLインジェクション、コマンドインジェクション、コードインジェクション）
- 認証の不備およびアクセス制御の不備
- 安全でない暗号化の使用
- ハードコードされたシークレット
- 安全でないデータフロー
- ビジネスロジックエラー
これらは、最も一般的なOWASP Top 10カテゴリに密接に対応しています。
最高のSASTツールは、AIを活用したトリアージも提供し、実際のリスクを優先し、誤検知を排除し、修正を実装します。
SASTツールはソースコードをどのように分析しますか？
SASTツールは、コードを実行せずに分析します。
それらは次のような手法を使用します。
- パターンおよびルールベースの分析。
- データフローグラフと制御フロー分析。
- 入力から危険なシンクまでのテイントトラッキング。
- フレームワークとAPIのセマンティックな理解。
これにより、コードがリアルタイムで記述されている間でも、SASTは問題を早期に発見できます。
SAST、DAST、SCA、IASTの違いは何ですか？
- SAST (Static Application Security Testing): ランタイム前に脆弱性を見つけるためにソースコードを分析します。
- DAST（Dynamic Application Security Testing）： 稼働中のアプリケーションを外部からテストし、ランタイムの問題を発見します。
- SCA（ソフトウェア構成分析）: サードパーティの依存関係における既知の脆弱性やライセンスリスクをスキャンします。
- IAST（インタラクティブ・アプリケーション・セキュリティ・テスティング）： インストゥルメンテーションにより、ランタイム中のアプリケーションの動作を監視します。
各手法は異なるリスク領域をカバーします。いずれか一つだけでは不十分です。
