SAST vs.SCA テスト: 違いは何ですか？組み合わせて使えますか？
著者:
0 分で読めます
開発者が最新のセキュアコーディングガイドラインにどれだけ準拠していても、その意図がどれほど完璧であっても、一部の製品コードにはほとんどの場合、少なくとも一つのセキュリティ問題が含まれています。開発者も人間ですから、ソフトウェアの潜在的な脆弱性が大量に存在し、かつ増え続けていることと、リリースサイクルを早めるというプレッシャーとのバランスを取ることに直面したとき、何かを犠牲にしなければなりません。
ここでは、静的アプリケーションセキュリティテスト (SAST) とソフトウェアコンポジション解析 (SCA) について、その基本的な考え方、利点、および違いについて詳しく見ていきましょう。また、SAST と SCA を活用し、この 2 つを組み合わせて安全なソフトウェアをリリースし、真に安全なアプリケーションを開発する方法についても説明します。
SAST と SCA とは
静的アプリケーションセキュリティテスト (SAST) は、ドキュメント (要件、設計、仕様) やアプリケーションソースコードなどの多様な静的入力を評価して、様々な既知のセキュリティ脆弱性をテストする構造的なテスト手法です。簡単に言えば、SAST は、作成したコードをスキャンしてセキュリティの脆弱性を探すために使用されます。
一方、ソフトウェアコンポジション解析 (SCA) は、開発チームがプロジェクトに持ち込まれたオープンソースコンポーネントをすばやく追跡して分析するアプリケーションセキュリティ手法です。簡単に言うと、SCA は依存関係をスキャンしてセキュリティの脆弱性を探すために使用されます。
SAST が重要な理由
SAST には多くの利点がありますが、最も重要なのは、セキュリティの脆弱性を検出し、ファイル名や行番号を含めてその位置を正確にマークする機能です。検出された各脆弱性に対して、SAST ツールはその重大度を示し、簡単な説明を提供します。重要なのはピンポイントで問題を特定する機能です。開発者の作業で最も時間のかかる作業の一つが問題を特定することだからです。
SCA テストが重要な理由
最近のアプリケーションは、オープンソースのコードで構成されることが多くなっています。アプリケーションのコード構成のうち、オープンソースコードが占める割合は 80 ～ 90% と言われています。そして、このように信頼できるオープンソースコードが広く利用できるようになったことで、開発チームはこれまで以上にすばやくアプリケーションを構築できるようになりました。
もちろん、アプリケーションは組織にネイティブなコードだけで構成されているわけではありません。実際、コードベースのセキュリティを確保しようとする組織が直面する課題の一つは、アプリケーションが様々な構成要素から組み立てられているため、リスクを効果的に管理し軽減するためには、すべての構成要素のセキュリティを確保する必要があるという点です。
SAST vs.SCA
ここまで SAST と SCA の利点について見てきましたが、それぞれのテクノロジーの機能の違いを調べ、どちらのアプローチが導入する組織に適しているか判断してみましょう。
SAST が異なる点
前述の通り、SAST の最大の利点は、静的なアプローチで実行中のアプリケーションを必要としないため (コード行のみが必要)、開発の初期段階から利用できることです。通常、SAST が最も効果的に機能するのは以下の方法です。
アプリケーションを「内から外に」分析する
SDLC の全段階で実行する
通常はツールで解釈可能なビルドモデルの作成が必要
解析を一連のルールに基づいて行う
得意分野の異なる複数の解析タイプで実行
SAST の 5 つの分析タイプ
SCA が異なる点
上記のように、SCA の手法やツールを導入している組織は、オープンソースソフトウェアに依存しています。通常、最も効果的に機能するのは以下の方法です。
オープンソースコンポーネントを特定する: アプリケーションを解析し、直接依存または推移的依存のいずれかによる、オープンソースパッケージへの依存を特定します。Snyk の調査によると、脆弱性の 80% は相互依存関係によってもたらされるため、この機能は効果的にリスクを軽減するために非常に重要です。
ライセンスコンプライアンス管理: 使用されている様々なオープンソースライセンスを特定し、オープンソースソフトウェアに関連する法的リスクの軽減に役立てることができます。組織は、SCA ツールを使ってライセンスポリシーを確立し、開発の初期段階での法的リスクを回避することができます。
セキュリティの脆弱性:脆弱性データベースと関連付けて、オープンソースの依存関係にあるセキュリティの脆弱性を特定します。特定した後、一部の SCA ツールは対策を促進にするための情報も提供します。たとえば、Snyk は、コンテキストに沿った完全な修正アドバイスと、正確なセキュリティパッチを提供し、チームがタイムリーに脆弱性を処置できるよう支援します。
ガバナンスとコントロール: ソフトウェア開発ライフサイクルの様々な段階で、セキュリティおよびライセンスポリシーを自動的に適用します。SCA ツールでは一般に、オープンソースのセキュリティテストを CI/CD プロセスに統合されており、脆弱性がデリバリーパイプラインの先に進まないようになっています。
報告および分析:ソフトウェア部品表 (SBOM) の作成 - コード内で使用されている様々な依存関係と、それらがコード内のどこで使用されているかを詳細にリストアップします。これらのレポートは、将来のセキュリティリスクを評価するために使用し、他の関係者と共有して、標準化をサポートできます。
アプリケーションセキュリティにおける SCA とは
SCA 自体は新しいものではありませんが、ここ数年、オープンソースが普及したことで、アプリケーションセキュリティの重要な柱となっています。その結果、多数の SCA ツールが出現しました。ただし、すべての SCA ソリューションが同じというわけではありません。DevSecOps の概念を含む最新のソフトウェア開発プラクティスにおいて、開発者ファーストで SCA を実施することが求められます。つまり、開発チームには使いやすいツールが提供され、セキュリティチームには開発者をガイドする機能が提供されます。それ以外にも、コンプライアンス監査機能や AI および ML 機能が差別化要因になり得ます。
SAST と SCA: アプリケーションセキュリティの複合的なアプローチ
この 2 つのテクノロジーを比較してみると、効果的なセキュア開発のためには、どちらも必要であることがわかります。SAST では作成したコードの解析に役立ちますが、SCA では利用するオープンソースソフトウェアとその依存関係を効果的に解析できます。この 2 つのテクノロジーにより、開発ライフサイクルの早い段階で、頻繁にセキュリティ問題に対処できるようになります。
複合的なアプローチにより、幅広く脆弱性や攻撃対象となり得る弱点を発見でき、セキュリティテストにおいて、SAST および SCA の動的なアプローチの両方のメリットが得られます。また、ネイティブコードとオープンソースコードの両方を完全にカバーすることができるようになります。