ソフトウェアやシステムの脆弱性を検出する技術は複数あります。有能な組織は「セキュリティ道具箱」にそれらの技術を備え、次のようなテストツールを組み合わせて使っています。
- 静的解析セキュリティテスト（SAST)
- 動的解析セキュリティテスト（DAST)
- ソース構造解析（SCA)
- 脆弱性スキャナー
- ペネトレーションテスト
自動化されたツールでセキュリティを向上させようという試みの背後には、ソフトウェア開発ライフサイクル（SDLC)の中で、脆弱性の検出と修正をできるだけシフトレフトさせたいという動機があります。修正と対処は、アプリケーションがリリースに近づくほど難しくなります。図 1 は、SDLCが進行するにつれて、脆弱性の修正にかかるコストが劇的に増大することを示しています。
ソフトウェアセキュリティの経済的側面を深く掘り下げた考察については、ホワイトペーパー『The Business Value of Secure Software』を参照してください。この記事では、特に組織のセキュリティプラクティスの一環として静的解析セキュリティテストを行う方法について説明します。
静的解析セキュリティテスト
SASTツールはアプリケーションを実行する必要がないため、修正コストが低い開発ライフサイクルの早期に利用できます。基本的に、SASTはソースコードを解析し、ルールセットと照らし合わせてチェックします。通常、脆弱性の検出に関連して、SASTツールは悪用されるおそれがある良くないコーディングパターン、セキュアコーディングポリシーへの違反、機能の安定性または信頼性の低下の原因になるようなエンジニアリング標準への違反を早期に警告します。
セキュリティの問題を検出するのに使われる解析のタイプは主に次の2つです。
- フロー解析
- パターン解析
フロー解析
フロー解析では、ツールはソースコードを解析し、コードの制御フローとデータフローを把握します。
結果として、アプリケーションの中間的な表現、つまりモデルが生成されます。ツールはモデルに対してツール（チェッカー）を実行し、セキュリティ脆弱性につながるコーディングエラーを検出します。たとえば、CまたはC++のアプリケーションでは、文字列のコピーを検出すると、モデルを検証して、コピー元のバッファーがコピー先のバッファーより大きい可能性がないかどうかを確認します。コピー元のバッファーがコピー先のバッファーより大きい場合、バッファーオーバーフローの脆弱性につながる可能性があります。
パターン解析
AUTOSAR C++14、MISRA C 2012、Joint Strike Fighter (JSF)などの最近のソフトウェアエンジニアリング標準の背後にあるのは、セーフティクリティカルなコードでは特定の構造を避けるという考え方です。これらの標準は、解釈の誤りや誤解、誤って信頼性のないコードを実装してしまう可能性を防ぎます。
パターン解析は、セーフティまたはセキュリティを考慮した場合に、比較的安全である開発言語サブセットの使用を推進し、脆弱性につながる構文の使用を最初から禁止するのに役立ちます。一部のルールは、ワープロのスペルチェッカーのように構文をチェックすることでエラーを検出します。最近のツールには、良くない構文に関連するわかりにくいパターンを検出できるものもあります。
SASTの利点
どのテスト手法にもそれぞれ強みがあります。多くの組織では、DASTやペネトレーションテストに重点が偏りすぎています。しかし、SASTには他のテスト手法にまさる利点がいくつかあります。
コードカバレッジ
ソフトウェアセキュリティにとって、どれだけコードがテストされたかは重要なメトリクスです。脆弱性はコードのどこに存在していてもおかしくありません。テストされていない部分がアプリケーションを攻撃にさらす可能性があります。
SASTツール、特にパターン解析ルールを使用するものは、動的手法や手動プロセスよりもはるかに高いカバレッジを実現できます。SASTは、ユーザーインターフェイスには表れないものも含め、アプリケーションのソースコードと入力にアクセスできます。
根本原因の解析
SASTツールは脆弱性の効率的な修正を促進します。静的解析セキュリティテストは、エラーが入り込んだまさにその行を簡単に指摘できます。開発者のIDEと統合することで、SASTツールが発見したエラーの修正はさらに加速されます。
スキルの向上
開発者はIDEからSASTツールを実行したとき、コードへのフィードバックをただちに受け取ります。そのデータは、セキュアなコーディングプラクティスに関する開発者の知識を高め、開発者を教育します。
運用の効率性
開発者は、IDEから個別のファイルをチェックするなど、開発ライフサイクルの早期に静的解析を使用します。SDLCの早期にエラーを発見すると、修正コストが大幅に削減されます。最初からバグを防ぐので、開発者は後でバグを発見して修正する必要がありません。
SASTの効果を最大化する方法
SASTは網羅的なテスト手法ですが、導入を成功させるには、最初にいくらか努力とモチベーションが必要です。
できるだけ早期にSASTを配置する
SDLCの早期にSASTツールを利用できているチームがあるいっぽうで、テストフェーズになるまで解析を遅らせることを選ぶ組織もあります。より完成に近いアプリケーションを解析すれば、手続きをまたぐデータフローを解析できるのもたしかですが、SASTを「シフトレフト」し、IDEから直接コードを解析すると、入力の検証エラーなどの脆弱性を検出できます。また、コードをサブミットしてビルドされる前に簡単にエラーを修正することもできます。これは、セキュリティのためにサイクルの後期に変更が行われるのを防ぐのに役立ちます。
CI/CDパイプラインとSAST
SAST解析は誤解されています。多くのチームは、SASTはプロジェクト全体のソースコードを深く解析するため、時間がかかると考えています。これは、SASTがペースの速い開発手法とは相容れないと思われる理由にもなっていますが、事実ではありません。開発者のIDE内でほぼ即時にSASTの結果を見ることができ、即時フィードバックを受け取って脆弱性を回避することができます。最新のSASTツールはインクリメンタル解析を実施し、ビルド間で変更されたコードの結果だけを表示します。
結果のノイズに対処する
従来のSASTツールは、多数の「情報」レベルの結果や正規のコーディング標準の周辺にある重要度の低い問題を結果に含めます。Parasoft製品などの最新のツールでは、ユーザーがエラーの重要度に基づいて使用するルール/チェッカーを選択し、調査するほどではない結果を非表示にできます。OWASP、CWE、CERTなどが公開しているセキュリティ標準の多くには、重大な脆弱性だけを識別するのに役立つリスクモデルがあります。このような情報を利用し、最も重要な問題への集中をサポートするSASTツールを使用するべきです。プロジェクトのメタデータ、コードの古さ、コードを担当する開発者やチームなどのコンテキスト情報に基づいて、さらに指摘事項をフィルターできます。Parasoftをはじめとするツールは、これらの情報を人工知能（AI)と機械学習（ML)で処理し、最も重要な問題の判別をさらに支援します。
開発者の重視
開発者を重視したことが導入成功の要因だったケースが多くあります。そのような例では、開発者がセキュリティをソフトウェアに組み込むために必要なツールとガイドが提供されています。これは速度を維持するために迅速なフィードバックが不可欠なアジャイルやDevOps/DevSecOps環境にとって重要です。IDEとの統合により、ファイルレベルでも、プロジェクトレベルでも、さらには変更したところだけを評価するのでも、開発者の作業環境から直接セキュリティテストを行うことができます
高度なルール設定を利用する
セキュリティの問題を発見するためにソフトウェアを解析する際、すべての組織にぴったりというものはありません。ルール/チェッカーが特定のアプリケーションにとって重要な特定の問題に対処できることが不可欠です。セキュリティを目的としたテストを始めたばかりの組織は、クロスサイトスクリプティングやSQLインジェクションなどのよく知られたセキュリティの問題に関するルールだけに絞りたいと考えるかもしれません。他の組織にも、PCI DSSなどの規制に基づいた固有のセキュリティ要件があるでしょう。汎用的な設定ではなく、固有のニーズに合わせてルール/チェッカー設定を制御できるソリューションを探しましょう。
予防は検出にまさる
セキュリティをアプリケーションに組み込みましょう。これは、SDLCの最後で、完成したアプリケーションにセキュリティを後付けすることでアプリケーションのセキュリティを確保しようとするより、はるかに効果的かつ効率的です。テストでアプリケーションにセキュリティを作りこむことが不可能なのは、品質の場合と同様です。SASTは早期検出の鍵であり、最初からセキュアなコードを書くことでセキュリティ脆弱性を防ぎます。
SASTツールを利用すると、開発の初期段階からソフトウェアセキュリティを包含し、セキュアなソフトウェアを構築するのに必要なツールとガイドをソフトウェアエンジニアに提供することができます。
（この記事は、開発元Parasoft社 Blog 「Add Static Analysis to Your Security Testing Toolbox」2020年8月26日の翻訳記事です。）
Parasoft Jtestについて
