SASTとSCAの違い・使い分け｜自動検査の範囲と異常系・回帰試験

SASTとSCAの違いは調べる対象だ。SASTは自社で書いたソースコードを、SCAは取り込んだOSSなどの部品を検査する。

SASTは、ソースコードを実行せずに解析し、危険な書き方を探す。SCAは、部品の名前とバージョンを、公表済みの脆弱性情報と照合する。

どちらも、認可や業務ルールの誤りと、未報告の部品の不具合は見つけにくい。公開する機能を確かめるには、SAST・SCAに、境界値・不正入力の試験と修正後の回帰試験を組み合わせる。

SASTとSCAで検出できる脆弱性の違い

SASTは自社コードの型の決まった誤りを、SCAは脆弱性が公表済みの部品のバージョンを見つけやすい。下の表は、動作試験も含めた分担だ。

SASTと並べて語られるDASTは、動いているWebアプリを外側から自動で検査する道具だ（OWASP「脆弱性スキャンツール」）。表の動作試験のうち、自動で回せる部分にあたる。

SASTによるコードの検査範囲

OWASPは「ソースコード解析ツール」の解説で、SASTはSQLインジェクションやバッファオーバーフローのような既知の型の脆弱性を見つけ、問題のファイル名と行番号まで示せると書いている。同じ解説によれば、認証の問題、アクセス制御の不備、暗号の誤った使い方は自動で探しにくく、コードにない設定の問題も見つけにくい。誤検知も多いという。

SASTが判定するのは、その書き方が危ないかどうかまでだ。誰がどの条件でその処理を呼んでよいかは、コードの外の仕様が決める。

SCAによる依存部品の脆弱性確認

SCAの例として、OWASPのOSSであるDependency-Checkは、ファイルから製造元・製品名・バージョンの手がかりを集め、NVD（米国の脆弱性データベース）の製品識別子と突き合わせて、該当する脆弱性を報告する（「Dependency-Checkの仕組み」）。推定なので誤検知も見逃しもありうると、同じ文書は書いている。SCAは部品のライセンス特定にも使う（OWASP「コンポーネント分析」）。

SCAが警告できるのは、脆弱性が公表され、影響するバージョンが登録された部品に限られる。OWASPの「ソフトウェアサプライチェーンセキュリティ チートシート」は、直接の依存と推移的な依存（部品が使う部品）を脅威の入口とし、棚卸しした部品の既知の脆弱性の監視を求める。

SAST・SCAの導入と検査対象の除外条件

SAST・SCAは変更のたびと定期的に実行し、外す警告には理由と期限を付けて記録する。検査に通ったと言える範囲は、その記録で決まる。

SAST・SCAの実行時点と対象

米国のNISTは「セキュアソフトウェア開発フレームワーク」（SSDF）で、コードを登録するたびに自動ツールで確かめる例と、部品の既知の脆弱性を見つける仕組みを開発の道具立てに組み込む例を挙げている。公表された脆弱性を定期的に確かめる例もある。

SCAの結果は、コードを変えない日にも変わる。新しい脆弱性が公表されると、前日まで警告のなかったバージョンが対象に入るからだ。変更時の検査に加え、公開中のソフトウェアの部品一覧（SBOM）も定期的に照合する。SSDFは見つかった問題を課題管理などに記録し、トリアージするよう求める。記録には担当者と修正期限も書く。

検査除外と未確認箇所の管理

誤検知を減らす除外は必要だが、広く外すほど結果に出ない箇所が増える。Dependency-Checkの除外設定では、CVSS（深刻度の点数）が一定未満の脆弱性をまとめて外す書き方もできる。OSSのOSV-Scannerでは、設定で部品全体やディレクトリ全体を無視できる。

除外には理由と期限を書く。どちらのツールも除外に期限の日付を付けられ、その日を過ぎると除外が効かなくなる。SASTでは、ビルドできないコードは解析しにくいとOWASPが指摘している。解析できなかった箇所は「未確認」として残す。

SAST・SCAを補う境界値・不正入力の試験

SAST・SCAが扱わない入力の誤りと認可の不備は、仕様から試験ケースを作り、期待する拒否やエラーまで書いて、ソフトウェアを動かして確かめる。

境界値・不正入力の試験

SSDFは、実行できるコードの試験の例に、入力処理の問題を見つけるファジングを挙げている。ファジングは、想定外の形や壊れかけの入力を自動で大量に与え、異常終了や想定外の動作を探す手法だ。OWASPの「ファジング」の解説は、整数なら0、負の数、非常に大きな数を試す例を挙げている。

境界値の試験では、仕様が決めた上限・下限の前後を試す。上限ちょうどの値、上限を1つ超えた値、空の値、形式の違う値を、期待する結果と一緒に試験ケースにする。ファイルを受け取る機能なら、サイズの上限、空のファイル、拡張子と中身の形式が食い違うファイルが候補になる。

認可・業務ルールの試験

OWASPの「Webセキュリティテストガイド」（4.2）は、業務ロジックの脆弱性はDASTのような脆弱性スキャナーでは検出できず、乱用ケースの試験は自動化できないと書いている。例は、手順1・2・3の順で認証する仕組みで、手順1から3へ直接進んだ場合の動作だ。

利用者、データの持ち主、処理の状態の組み合わせを表にし、許可と拒否の期待結果を試す。拒否すべき組み合わせは業務の仕様で決まるので、仕様の担当者と期待結果をすり合わせる。

他人の注文のように、データごとの権限確認が抜ける不備がなぜ起きるかと、修正後に許可と拒否を確かめる方法は、BOLAの記事で整理している。

脆弱性修正後の回帰試験とSCAの再検査

脆弱性を直したら、問題が起きた条件を再現する試験を残し、SCAも実行し直す。回帰試験は、直した弱点が後の変更で再び現れないかを確かめる試験で、SSDFは過去に報告された脆弱性の試験を試験群に組み込む例を挙げている。

ChatGPTで他の利用者の会話の題名や支払い関連の情報が表示された事故は、OpenAIの3月24日の報告によれば、OSSのRedisクライアント「redis-py」の不具合が原因だった。要求を送ってから応答を受け取るまでの間に要求が取り消されると、共有の接続にデータが残り、次の無関係な要求がそれを受け取った。多くはサーバーのエラーで終わったが、型が合うと他人のデータが正しい応答として返った。同社は、特定の9時間に活動していたChatGPT Plusの契約者の1.2%について、支払い関連の情報が他人に見えた可能性があるとしている。

NVDの記載によれば、ChatGPTの報告を受けて作られた1件目（CVE-2023-28858）の修正はパイプライン操作の動作を変えるもので、接続をまたぐ漏えい全般への対処は2件目（CVE-2023-28859）の修正で行われた。

1件目で更新しただけの環境も、SCAを実行し直せば2件目の検出の対象になる。この事故から、回帰試験には次の条件を入れる。

1. 要求の取消、タイムアウト、例外のあとに、同じ接続を次の要求に使う
2. 複数の利用者の要求を並行して送る
3. 返ったデータの持ち主と、要求した利用者が一致するかを判定する

OpenAIも対策として、キャッシュから返るデータが要求した利用者のものかを重ねて確かめる処理を加えたと書いている。正常に完了する要求だけを流す試験では、3の判定が失敗する場面が生まれない。

公開事例をセキュリティテストの回帰試験に加える方法

公開事例は成立条件に分けて自社と照合し、同じ条件があれば回帰試験に加える。事例と自社の違いも記録し、試験を加えなかった理由を残す。SSDFも、脆弱性の根本原因を分析し、似た脆弱性がないかソフトウェアを見直す作業を挙げている。

redis-pyの事故なら、同じ部品を影響するバージョンで使っているか、非同期処理で接続を複数の要求で共有しているか、要求の取消やタイムアウトが起きるか、キャッシュに利用者ごとのデータを入れているかを照合する。

公開前の検証計画では、SAST・SCAの対象と除外を一覧にし、どちらにも入らない入力・認可・取消の条件を動作試験に割り当てる。修正後は、その試験とSCAの再実行がともに通ることを確かめる。