このブログは アプリケーション・セキュリティ・テストツール の 市場分類を紹介する、WhiteSource社のブログ翻訳シリーズの第3回です。
前回は、WhiteSourceが含まれる SCAツールについて説明しました。

今回は、アプリケーションセキュリティテストのツール市場の中で、最も利用されている 静的アプリケーションセキュリティテスト (Static Application Security Test : SAST) をご紹介していきます。

■本ブログの目的

SASTツールは静的解析ツールと呼ばれることもあり、商用製品以外にも無償で利用できるツールも多く存在しています。
恐らく、このブログを読んでいる方の中にも 既に何らかのSASTツールを利用されているのではと思います。
今回翻訳したWhiteSource社のブログでは そんなSASTツールについて、アプリケーションセキュリティテスト全体で見た時の特徴とメリット・デメリットを説明しています。
ブログを読んで頂くことで、SASTの立ち位置をより深く理解し、SASTだけでは足りないことなども知って頂ければと思います。

静的アプリケーションセキュリティテスト（Static Application Security Testing：SAST）は、過去15年間、アプリケーションセキュリティ対策の中心的な役割を果たしてきました。
Forrester社が最近発表した「State Of Application Security Report」の2020年の予測では、アプリケーションの脆弱性が今後も最も一般的な外部攻撃手法になるとされていることを考えると、SASTは当面の間、使われ続けると言ってよいでしょう。

Forrester社によるセキュリティ専門家を対象とした調査の結果では、2019年における攻撃の大半は、ソフトウェアの脆弱性を悪用したもの（42％）か、Webアプリケーションを介したもの（35％）であることがわかりました。
SASTはアプリケーションセキュリティテストツールの代名詞となっていますが、本当にソフトウェア製品のセキュリティを確保したいのであれば、使用しているツールがどのように機能し、その価値を最大限に引き出す方法を知ることが重要です。

他のテクノロジーと同様に、特にセキュリティに関しては、SASTにも長所と短所があります。
SASTは、潜在的な脆弱性を検出することができますが、開発を遅らせる可能性もあります。
だからこそ、SASTがどのように機能するのか、その長所と短所、そしてどうすれば改善できるのかを理解することが重要です。

■SASTとは

静的アプリケーション・セキュリティ・テスト（SAST）は、現在使用されている最も成熟したアプリケーション・セキュリティ・テスト手法の1つであり、コンポーネントが静止している時にソースコードを内側から分析する、ホワイトボックステストになります。
ガートナーによるSASTの定義は「アプリケーションのソースコード、バイトコード、バイナリを分析して、セキュリティの脆弱性を示すコーディングの状態を調べるように設計された一連の技術」となっています。

■SASTはどのように機能するのか？

その名が示すように、SAST は静的なコードをスキャンし、コードを実行することなく、静止状態でテストします。
SASTは通常、開発のコーディングとテストの段階で実装され、CIサーバー、あるいは最近だと IDEと統合されています。
SASTはチームが開発したコードをスキャンして、セキュリティの脆弱性を引き起こすかもしれない弱点を検出します。

SASTのスキャンは、対応や検証が必要なソースコード内のコーディングエラーを予め定義した一連のルールに基づき行われます。
SASTスキャンは、SQLインジェクション、入力検証、スタック・バッファ・オーバーフローなど、一般的なセキュリティ脆弱性を特定するように設計することができます。

■SASTの長所と短所

まず、良いニュースから始めましょう。
SASTは、トップレベルのアプリケーション セキュリティ ツールであり、正しく実行しさえすれば、組織のアプリケーションセキュリティ戦略に不可欠な物です。
SASTをSDLC (ソフトウェア・ディベロップメント・ライフ・サイクル)と統合することで、組織のセキュリティプロファイルを向上させることができます。
ここでは、スタティック・アプリケーション・セキュリティ・テストの主な利点を紹介します。

【長所】

#1 セキュリティのシフトレフト

ソフトウェア開発の初期段階にセキュリティテストを組み込むことは重要なプラクティスです。
SASTは、セキュリティ・テストをシフトレフトし、プロプライエタリ・コードの脆弱性を解決が比較的容易な設計段階で検出できるようになります。
この段階でセキュリティの問題を発見して修復することは、リリース日直前、最悪の場合はリリース後に対処するというコストのかかる作業を省くことができます。

#2 安全なコーディングの実現

SASTは、非常にシンプルなコーディングエラーに起因する欠陥を容易に検出し、開発チームが安全なコーディング基準とベストプラクティスに準拠していることを確認するのに役立ちます。

#3 一般的な脆弱性の検知

自動化されたSASTツールは、バッファオーバーフロー、SQLインジェクション、クロスサイトスクリプティングなど、一般的なセキュリティ脆弱性を高い信頼性で簡単に検出することができます。

【短所】

残念ながら、SASTは過去15年間使用されてきた非常に成熟した技術ではありますがまだ欠点もあります。
SASTの主な弱点は次のとおりです。

#1.すべての脆弱性をカバーしていない

認証、アクセス制御、暗号などの問題は、稼働前のソースコードから自動的に検出することは困難です。
当然のことながら、SASTは実行時の問題や設定の問題もカバーできないため、追加のセキュリティ・テスト・ツールを導入する必要があります。

また、SASTはオープンソースの脆弱性もカバーしません。
今ではアプリケーションは60%～80%がオープンソースのコンポーネントで構成されているため、コードのかなりの部分がテストされないままとなるのでSCAツールが必要となります。

#2 偽陽性の多い

SASTの結果には多くの偽陽性が含まれており、開発チームやセキュリティチームは、真の問題を探すために誤った警告を取り除くことに多くの時間と労力を費やしています。
競争の激しい開発ペースや重要な問題の修正にかかる時間を考慮すると、偽陽性というノイズに対処することは、開発にかなりの負担をかけることになります。

#3 時間がかかる

自動化されたSASTは連続的にスキャンすることができますが、コードベースが大きいと、1回のスキャンに数時間かかることがあります。
また、結果が出た後には分析が必要になります。
SASTは潜在的な脆弱性を指摘することしかできず、疑わしい弱点が本当にセキュリティリスクであるかどうかの検証は開発者に委ねられます。

■組織に合ったSASTツールの選び方

AST市場にはSAST製品が溢れており、追加のソリューションがバンドルされていることも多く、自分達に合ったツールを見つけるのは難しかったりします。

OWASP の正しい SAST ツールを選択するための基準リストは、選択肢を絞り込み、アプリケーションセキュリティ戦略の改善に最も役立つソリューションを選択するのに役立ちます。

言語サポート：最も重要な点は、組織がどのプログラミング言語を使用しているかということです。
使用しているSASTツールが、これらの言語を完全にカバーしていることを確認してください。

脆弱性のカバー率：SASTツールが、少なくともOWASPのウェブ・アプリケーション・セキュリティの脆弱性トップ10のすべてをカバーしていることを確認してください。

正確性：正確性はSASTの弱点であり、偽陽性や偽陰性は常に存在しますが、検討しているSASTツールの正確性を確認することは重要です。

互換性：他の自動化ツールと同様に使用するSASTツールがSDLCと簡単に統合できるように、既に使用しているフレームワークでサポートされていることが重要です。

IDEの統合：IDEに統合可能なSASTツールは、貴重な修復のための時間を節約します。

簡単な統合：セットアップが簡単で、DevOpsパイプラインの他のツールとできる限りシームレスに統合できるSASTツールを見つけます。

スケーラビリティ：統合した SAST ツールが、明日にはより多くの開発者やプロジェクトをサポートできるように拡張できることを確認してください。
SAST ツールは、小さなサンプル プロジェクトでは素早くスキャンできるように見えますが、より大きなプロジェクトでも同じような結果が得られることを確認してください。
規模の拡大は、ソリューションのコストにも影響します。
OWASP のリストでは、ユーザーごと、組織ごと、アプリケーションごと、あるいは分析したコード1行ごとにコストが変わるかどうかを検討することが重要だと指摘しています。

■SASTは、アプリケーション・セキュリティ・ジャーニーにおける重要な要素

アプリケーション開発でセキュリティを確保するには、通常、価値とのトレードオフが必要です。
これはSASTにも当てはまります。
SASTは、組織の静的なコードベースをカバーして可視化するという点で、高い価値を提供します。
また、SASTはSDLCの早い段階で統合されるため、組織はセキュリティのシフトレフトを実現することができます。

しかし残念なことに、偽陽性が多く、SASTの結果をさらに分析する必要があることは、いずれもアジリティの大きな障害となっています。
今日のソフトウェア開発チームは、様々な課題に直面しています。
ソフトウェアの開発サイクルがますます短くなるにつれ、アプリケーション層への攻撃のリスクは継続的に上昇し、開発チームはセキュリティとスピードの両立に苦慮しています。

SASTを統合することで、すべてのセキュリティ脆弱性をカバーしてリスクを最小限に抑え、高品質な製品を競争力のあるスピードで提供するための適切なバランスを見つける努力が必要になります。

SASTは、セキュリティ・テスト市場の中で最も成熟していて、数多くのツールが存在しています。
故に 様々なナレッジも世に出ており導入も比較的簡単なため、SASTツールは導入しているというプロジェクトも多いのでは無いでしょうか？
また セキュリティテストに関してツールなどの導入をしていないプロジェクトであれば、まずは SASTツールの導入から始めることを検討すると良いと思います。

ですが、SASTにも欠点はあり、SASTだけでアプリケーションの脆弱性を検出するのは困難です。
分かりやすい点を挙げるのであれば、SASTは アプリケーションで開発したコード（プロジェクト・コード）のスキャンに特化しているため、オープンソース・コンポーネントのスキャンには対応していないという点です。
ですので、SAST に加えて、SCAツールも利用することで、プロプライエタリとオープンソースコンポーネントの両方の脆弱性をカバーするといったことが可能になります。

このブログはWhiteSource社の許可の下、
https://resources.whitesourcesoftware.com/blog-whitesource/sast-static-application-security-testingを翻訳したものです。

WhiteSource社 と WhiteSourceについては、WhiteSource.comをご覧ください。