SASTとSCA：Snykで組み合わせることで、より高い効果を

アプリケーションが複雑になるにつれて、その保護も難しくなります。

アプリケーションを構成するソースコードには、独自に開発したコードだけでなく、多くのサードパーティ製オープンソースコードも含まれています。安全なコードをリリースしながら開発のスピードも維持したい開発チームやセキュリティチームは、包括的なソフトウェアセキュリティ戦略の一環として、静的アプリケーションセキュリティテスト（SAST）とソフトウェア構成分析（SCA）を組み合わせる必要があります。

とはいえ、言うほど簡単ではありません。

従来から使われてきた、より歴史の長いテスト手法であるSASTは、アプリケーションセキュリティの最初の取り組みとして理にかなった選択肢でした。利用可能なSASTツールは数多くあり、選定に役立つ手法やベストプラクティスも十分に文書化されています。しかし、SASTソリューションには、速度、精度、使いやすさの面で評判がよくないという問題があります。こうした欠点が、チームによるSASTの導入を妨げたり、代わりにSCAを選ばせたりする可能性があります。

従来のSCAソリューションも大差はなく、統合が難しく、誤検知が多いという実績があります。オープンソースパッケージの脆弱性がSCAへの注目を高めているにもかかわらず、SCAの導入はまだ限定的で、オープンソースセキュリティ対策を利用していると回答した組織はわずか38%です。また、依存関係（およびその依存関係）をスキャンできても、SCAでは自社で記述したコードの脆弱性は検出できません。

しかし、SASTとSCAを個別に使うことは、ツールの乱立を抑え、アプリケーションセキュリティツールを統合したいという組織の高まるニーズに反しています。そのため、SAST または SCAのどちらかを選ぶ発想になりがちで、SAST と SCAを組み合わせて使うことが検討されません。

この記事では、SAST と SCAを組み合わせるべき理由と、ツールを乱立させずに両方を導入する方法をご紹介します。

SASTとSCAの違いとは？

SASTとSCAの違いを理解することは、両者を組み合わせたアプローチの導入に大きく役立ちます。

SASTの用途とは？

SASTは、アプリケーションのソースコードやバイトコードをスキャンし、OWASP Top 10やCWEなどのセキュリティ脆弱性を検出する、構造的なアプリケーションセキュリティテスト手法です。ソースコードやバイトコードのほか、ドキュメントや仕様書など、さまざまな情報も評価できます。最新のSASTツールは元のコードを中間表現に変換し、通常は論理ソルバー上で動作するルールセットを使って、さまざまな種類のテストを実施します。

SASTの利点は、アプリケーションが取り得るあらゆる実行経路や状態を網羅し、開発者が当初想定していなかったバグも検出できることです。検出された問題には、ファイル名や行番号を含む、アプリケーション内の正確な場所や経路を示す情報と、問題そのものに関する詳細を付記する必要があります。

従来のSASTツールの欠点の1つは、ツールベンダーが、真の問題を検出すること、考えられるすべての問題を検出すること、計算リソースの使用量という3つの要素のバランスを取らなければならない点です。そのため、従来のツールではアプリケーションの挙動を過大に見積もり、計算時間を優先する代わりに、一定数の誤警告や見落としを許容する妥協が生じます。それでも、大規模なプロジェクトでは、従来のSASTツールによるスキャンに数日、場合によっては数週間かかることがあります。

SCAの用途とは？

最新のアプリケーションは、数十から数百に及ぶこともあるオープンソースパッケージ（依存関係）に依存しています。実際、アプリケーションの98%にオープンソースソフトウェアが含まれています。これらの依存関係も、推移的依存関係と呼ばれる別のオープンソースパッケージに依存しています。オープンソースパッケージは、テキストの書式設定といった単純なタスクから、複雑なフレームワークやランタイムまで、幅広い用途を担っています。

オープンソースパッケージは、ひとまとまりのものとして扱うのが一般的なベストプラクティスです。コードのパッチ適用や変更は、それをパッケージに提供し、取り込んでもらう限り歓迎されます。ローカルで変更するとパッケージのバージョン管理が崩れ、新しいバージョンをダウンロードした際に変更が上書きされる可能性があります。

SCAは、アプリケーションで直接または間接的に使用されているオープンソースの依存関係をスキャンし、その分析結果を脆弱性データと照合して、依存関係に含まれる可能性のある既知のセキュリティ脆弱性を追跡するアプリケーションセキュリティ手法です。脆弱性が見つかると、脆弱性そのものに関する情報が通知され、場合によっては推奨される修正方法も提示されます。重要な点として、SCAはオープンソースパッケージに含まれるライセンスを特定し、オープンソースの利用によって生じる法的リスクの把握にも役立ちます。

SASTとSCAを併用する理由

2つのテスト手法には機能上の違いがあるため、同じ条件で単純に比較するのは適切ではありません。

開発プロセスの早い段階で導入され、ソースコードをテストするなどの共通点はありますが、アプリケーションを構成するコードの異なる2つのタイプを対象としています。SASTは社内で記述したコードがもたらすリスクの軽減に役立ち、SCAは組織外で記述されたコードがもたらすリスクの軽減に役立ちます。

したがって、効果的なアプリケーションセキュリティ対策には、両方のリスクを管理・軽減できるセキュリティテストツールを取り入れる必要があります。このアプローチにより、独自開発のコードとオープンソースコンポーネントを包括的に可視化し、開発ライフサイクルの早期から全体にわたって問題を特定・修正できるため、リスクを総合的に軽減できます。

併用アプローチに求められる要件

併用アプローチの選択は簡単ではありません。アプリケーションセキュリティプログラムの一環としてSASTとSCAの両方を導入するには、組織文化や技術面での課題があります。

DevSecOpsモデルでは、開発者がより大きな責任を担うことが求められます。しかし、従来のソリューションを過去および現在にわたって使ってきた経験から、開発者が1つのテスト手法を導入することさえ難しく、2つとなればなおさらです。すでに利用しているツールに、さらにセキュリティツールを追加することに抵抗を感じるチームもあるでしょう。

手軽な解決策は、SASTとSCAのツールをCI/CDパイプラインに統合し、検出結果を開発者に戻すことかもしれません。しかし、それではプロセスが分断され、スキャンの完了と修正の適用を待ってからデプロイすることになります。アジャイルなDevOpsの世界では、リリースを数週間遅らせることは現実的な選択肢ではありません。

そのため、併用型のアプリケーションセキュリティプログラムを成功させるには、何よりも開発者にとって使いやすいソリューションが必要です。既存の開発ワークフローに迅速かつ簡単に、早い段階から統合できるSASTおよびSCAツールのほうが、動作が遅く、使いにくく、開発の後期にしか導入できないツールよりも、開発者に利用されやすくなります。

さらに、SASTとSCAのスキャンを同時に実行する、あるいは同じツール内で実施できる統合ワークフローは、開発者の複雑さを軽減し、セキュリティにかかる全体的なコストも抑えます。

Snykのアプローチ：Snyk CodeとSnyk Open Source

SnykプラットフォームはSASTとSCAを組み合わせたアプリケーションセキュリティを提供し、今日のアプリケーションを構成するさまざまな要素を、安全かつ迅速に開発できるようにします。

SAST向けのSnyk Codeと、SCA向けのSnyk Open Sourceを併用すると、使いやすく、セルフサービスで利用できる、高速かつ高精度なテストを実現できます。開発者とセキュリティチームは、自社の独自コードにおけるセキュリティ上の問題と、オープンソースの依存関係に含まれる既知の脆弱性の両方を簡単に見つけ、優先順位を付けて修正できます。これにより、リスクを軽減し、安全な開発のスピードを高められます。

アプリケーションはCI/CDパイプラインに入る前に修正されるため、スキャン待ちによる遅延や、検出結果のトリアージおよび問題報告の作成といった負担がなくなります。これにより、アプリケーションセキュリティチームは組織全体のセキュリティ態勢に注力できます。

Snykの統合テストは開発の早い段階から、開発ライフサイクル全体にわたって実施できます。たとえば、IDE内から開始できます。

1つのツール、2つのスキャン方法：SnykのJetBrains IDEプラグインの実際の動作。

スキャンは短時間で完了し、結果は開発者の作業環境にわかりやすい説明とともに表示されます。アプリケーション内のデータフローを元のコードに重ねて表示し、複数のファイル間も移動できます。同様の状況で他の開発者がどのように問題に対処したかを示す、オープンソースプロジェクトの事例も確認できます。何より、スキャンが高速で回数に制限がないため、開発者は小さな変更も頻繁にスキャンし、ソースコード管理システムに反映する前に問題を修正できます。

Snykは、その後の開発段階でも統合スキャンを自動的に実施します。たとえば、GitHubから新しいプロジェクトをインポートすると、Snykはリポジトリ内のソースコードに対してSAST（1）とSCA（2）のテストを自動的に実行します。

Snykにインポートされたプロジェクト。SASTとSCAのスキャン結果を1つの統合ビューで確認できます。

重要な点として、SnykプラットフォームはSnyk Intel Vulnerability Databaseを基盤としています。このデータベースは、複数の公開情報源、Snykの大規模な開発者コミュニティからのフィードバック、Snyk専任の調査チームの成果を組み合わせ、市場でもっとも包括的で、タイムリーかつ実用性の高い脆弱性データを提供します。これにより、スキャン結果と対応する修正の推奨内容の精度が保たれます。

SnykのUIを使うと、開発チームとセキュリティチームは、新たに判明した脆弱性がないか、コードベースを定期的に監視できます。たとえば、最近のLog4shell脆弱性では、Snyk Open Sourceを利用することで、Snykユーザーはアプリケーションのコードベース全体を簡単かつ迅速にスキャンし、脆弱性のあるリポジトリを特定して、適切に対処できました。また、PRチェックを使ったり、SnykをCI/CDパイプラインに統合したりすることで、テストを自動化し、必須にできます。

Snykはスキャン数、コード行数、プロジェクト数に応じたライセンスではありません。アプリケーションセキュリティチームは、ライセンス費用を理由に重要なプロジェクトだけにスキャン対象を絞ったり、スキャン頻度を制限したりする必要はありません。必要なだけ、好きな頻度でコードをスキャンできます。

最後に、SnykプラットフォームはコンテナとInfrastructure as Code（IaC）の脆弱性もスキャンします（以前のスクリーンショットでお気づきかもしれません）。これにより、アプリケーションを構成するさまざまなコード要素を総合的に把握できます。

勝者は……両方

SASTとSCAは、組み合わせることでより高い効果を発揮し、組織は使用しているすべてのソフトウェアを網羅的に把握できます。

最新のアプリケーションを保護する取り組みには、その開発を支えるプロセスと同じ俊敏性が求められます。アプリケーションセキュリティでは両方のツールを使うことが今や事実上の標準となっており、PCI DSSや、アプリケーションセキュリティとソフトウェアサプライチェーン攻撃の増加に対応する世界各国の政府の取り組みなど、さまざまな規制要件への準拠においても求められるようになっています。

安全なアプリケーションを提供したい組織は、過去の経験や特定の手法への偏見、あるいは予算の制約を理由に、どちらか一方を選ぶ必要はありません。SASTとSCAは、アプリケーションを構成するすべてのソースコードを不可欠かつ包括的に可視化するため、あらゆるアプリケーションセキュリティプログラムの重要な要素となるべきです。

SASTとSCAをどう始めればよいかわからない方は、Snykを無料でお試しください。