本記事は2022年2月10日（米国時間）に公開した英語ブログSAST and SCA: Better together with 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のトップ10やCWEなどのセキュリティ脆弱性を検出する構造的なアプリケーションセキュリティのテスト手法です。ソースコードやバイトコード以外にも、ドキュメントや仕様など、様々な観点でソースを評価することができます。最新のSASTツールは、オリジナルコードを仮想サーバー向けの中間表現（バイトコード）に変換したうえで、保持しているルール集を用いて、複数種類のテストを実行します。

SASTの利点は、アプリケーション内のすべての経路と状態をカバーし、開発者が当初想定していなかったバグも発見できることです。バグが検出された際に、バグに関する追加情報とともに、ファイル名や行番号を含むアプリケーション内の正確な位置を記録します。

従来のSASTツールの欠点は、本当の問題を提示すること、起こりうるすべての問題を提示すること、使用済みのコンピュータリソース、この3点をツールベンダーがバランスをとらなければならないことです。そのため、ツールは、アプリケーションの動作を過大評価し、計算時間を優先して一定の割合の誤検知や問題の見落としを黙認する、といった水準を落とす仕組みとなっています。それでも、従来のSASTツールでは、大規模なプロジェクトをスキャンするのに数日から数週間かかることもあります。

SCAは何に使うのでしょうか？

最近のアプリケーションは、何十、何百ものオープンソースパッケージに依存しています。実際、アプリケーションの98%は、オープンソースソフトウェアを含んでいます。これらのパッケージは、それ自体が他のオープンソースパッケージに依存しており、推移的依存関係（transitive dependencies）と呼ばれています。オープンソースパッケージは、テキストの書式設定などの単純なタスクから、フレームワークやランタイムといったより複雑なタスクまで、さまざまなタスクに対応してます。

オープンソースパッケージを一つの単位として扱うことは、一般的なベストプラクティスです。バグ修正やコード変更はマージ(結合)される限り、パッケージに貢献するので歓迎しましょう。ローカルでの変更はパッケージのバージョニングを破り、新しいバージョンのパッケージがダウンロードされたときに変更が上書きされる可能性があります。

SCA はアプリケーションセキュリティの手法の一つで、アプリケーションをスキャンして、直接または間接的に使用されているオープンソースのパッケージを調べます。このパッケージについて、脆弱性データと関連付け、既知のセキュリティ脆弱性が含まれているか追跡することに焦点を当てます。脆弱性が検出されると、場合によっては推奨される修正方法に関する情報とともにその脆弱性の詳細が関連付けられます。重要なのは、SCAが、オープンソースパッケージに含まれるライセンスを特定することによって、オープンソースの使用による法的リスクのマッピングに役立つことも重要です。

SASTとSCAを併用すべき理由

この2つのテスト手法の機能的な違いから、単純に比較するのは間違いです。

開発プロセスの早い段階でソースコードのテストを実施するという共通点はあります。しかし、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への組み込みを皮切りに、開発ライフサイクルの早い段階で、横断的に行われます。

スキャンは迅速に行われ、結果は開発者用の作業画面内にわかりやすい説明付きで表示されます。アプリケーション内のデータフローは、異なるファイルへまたがる場合も含めてオリジナルコードと重ね合わせ表示されます。オープンソースプロジェクトの例として、他の人が同じような状況でどのように問題に取り組んだかが表示されます。何よりも、制約がなく高速であるため、開発者は小さな変更を頻繁にスキャンし、問題がソースコードのバージョン管理システムに到着する前に修正することができるのです。

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

重要なのは、Snyk プラットフォームが Snyk Intel Vulnerability Database に基づいていることです。これは、複数の公開ソース、Snyk の大規模な開発コミュニティからのフィードバック、および Snyk 独自の専門調査チームを組み合わせて、市場で最も広範囲で迅速、かつ最も実用的な脆弱性データを提供します。これにより、スキャン結果とそれに対応する修正アドバイスが正確です。

Snyk UI は、開発チームとセキュリティチームに、最近発見された脆弱性についてコードベースを定期的に監視する機会を提供します。たとえば、最近の Log4shell の脆弱性の場合、Snyk Open Source によって、Snyk ユーザーはアプリケーションコードベース全体に対して簡単かつ迅速にスキャンを実行し、脆弱なリポジトリを特定し、修正対応することができます。また、プルリクエスト(PR)チェックを使用したり、CI/CDパイプラインにSnykを統合したりすることで、これらのテストを自動化し、必須にすることもできます。

Snyk は、スキャンごと、コード行ごと、プロジェクトごとのライセンスではありません。アプリケーションセキュリティチームは、ライセンスコストのためにスキャンを重要なプロジェクトに絞ったり、一定のスキャン頻度へ制限することなく、好きなだけ、必要な頻度でコードをスキャンすることができます。

最後に、Snyk プラットフォームは、コンテナや infrastructure as code(IaC)の脆弱性もコードとしてスキャンし（以前のスクリーンショットでお気づきかもしれませんが）、アプリケーションを構成するコードの異なる部分すべてにわたって総合的なレポートを提供します。

勝者は...両者

SASTとSCAの組み合わせはより効果的であり、組織は使用されているすべてのソフトウェアを完全に把握できます。

最新のアプリケーションについて、セキュリティを維持する作業は、その開発を推進するプロセスと同じように迅速である必要があります。両方のツールを使用することは、今やアプリケーション・セキュリティのデファクト・スタンダードです。PCI DSSなどの準拠する規制要件が増えています。そして、世界中のさまざまな政府機関がアプリケーションセキュリティと拡大するソフトウェアサプライチェーン攻撃の課題に取り組んでいます。

セキュアなアプリケーションを提供しようとする組織は、これまでの経験や、特定の手法への偏り、あるいは限られた予算のために、1つの手法だけを選択する必要はないはずです。SASTとSCAは、アプリケーションを構成するすべてのソースコードに不可欠で統合的な可視性を提供するため、あらゆるアプリケーションセキュリティプログラムの重要なツールになるはずです。

ブログを読んで、Snykを使ってみたい！と思われた方は、ぜひ無料トライアルをお試しください。トライアル中の技術的なご質問は、サポートに日本語でお寄せください。

Snykでは、セキュアなコーディングのための情報や脆弱性の最新情報などを発信しています。ぜひTwitterやFacebookやブログのフォローをお願いします。