先に要点
静的解析を入れてみたが、指摘が多すぎて誰も見なくなった。あるいは全部通っているのに脆弱性が見つかった。どちらも、この手法が何を見ているのかを押さえれば説明がつきます。
この記事では、静的解析が得意なことと構造的に苦手なことを公式の整理で確認し、何と組み合わせれば穴が埋まるのかを整理します。
コードを動かさずに形を見る
静的解析はプログラムを実行せずに、ソースコードやその中間表現を読んで判定します。実行しないので、テスト用のデータも動く環境も要りません。書いた直後に回せるのが最大の利点です。
判定の対象になるのはコードの形です。入力がどこから来てどこへ渡るか、値の型が合っているか、到達しないコードがないか。こうした読めば分かることを網羅的に見ます。
得意なこと
OWASP の整理では、次の点が強みとして挙げられています。
- 規模に強い。大量のコードに対して、繰り返し実行できます。毎晩のビルドや継続的な検査に組み込めます
- 既知の型を見つける。バッファオーバーフローや SQL の組み立て方の問題のように、形が決まっている欠陥を検出できます
- 場所を示せる。ファイル名、位置、行番号、該当するコードの断片まで出せるので、開発者がそのまま直せます
3つ目が見落とされがちですが重要です。「どこかに問題がある」ではなく「この行」と言えることが、直す速度を決めます。
構造的に苦手なこと
こちらも公式にまとまっています。
| 苦手なこと | なぜか |
|---|---|
| 認証・権限・暗号の誤用 | 正しい形が1つに決まらない。仕様を知らないと判定できない |
| 設定に起因する問題 | コードの中に表現されていないので、読んでも出てこない |
| 本物かどうかの立証 | 到達しうる経路があることは言えても、実際に悪用できるかは別 |
| ビルドできないコード | 依存や手順がそろわないと解析自体が成立しないツールがある |
OWASP は現在のツールで自動的に見つけられるのは、アプリのセキュリティ上の欠陥のうち比較的小さな割合にとどまると明記しています。これは導入の失敗ではなく、手法の性質です。
誤検知が多いのは仕様に近い
同じ整理に誤検知が多いことも挙げられています。理由は単純で、安全側に倒して報告しているからです。
到達しうる経路があるなら報告する。実際には呼ばれない経路でも、コードの形からは区別できない。見落とすより多めに出す方が正しいという設計です。
問題は、その後の扱いです。全件を同じ重さで扱うと、量に負けて誰も見なくなります。現実的な運用は次の形です。
- 新規に増えた指摘だけを止める。既存の指摘は一旦棚卸しして別扱いにする
- 種類ごとに扱いを決める。止めるもの、警告にとどめるもの、無効にするものを分ける
- 無効にした理由を書き残す。書かないと、次の人が同じ判断をやり直します
2番を飛ばして全部を止める設定にすると、開発が進まなくなって結局オフにされます。
何と組み合わせるか
苦手な領域は、別の手段で埋めます。
- 動かして試す検査。実際にリクエストを送って挙動を見ます。設定や実行時の環境が絡む問題は、こちら側でしか出ません
- 依存しているものの検査。自分のコードではなく、使っているライブラリ側の既知の問題を見ます。静的解析とは対象が違います
- 人が読むレビュー。権限の設計や業務ロジックの妥当性は、仕様を知っている人しか判定できません
- 実環境の設定の確認。公開範囲や権限の付け方は、動いているものを見ないと分かりません
順番としては、静的解析を最初に置くのが合理的です。速くて何度でも回せるので、形に現れる分をここで落としておくと、後段の手間が減ります。
緑の意味を狭く読む
最後に、報告の読み方です。検査が全部通ったことは、「この手法で見える範囲に問題が無い」という意味でしかありません。
- 権限の設計が間違っていても緑になります
- 設定を公開のままにしていても緑になります
- 使っているライブラリに既知の問題があっても、対象外なら緑です
緑を「安全」と言い換えた時点で、判断を誤ります。何を見た検査なのかを添えて報告するだけで、この取り違えは防げます。
静的解析に関するよくある質問
Q. 静的解析と lint は違うものですか？
重なっています。どちらもコードを動かさずに読む手法で、書き方の統一を主目的にするものを lint、欠陥の検出を主目的にするものを静的解析と呼び分けることが多いですが、境界は製品によります。役割を整理して1つにまとめる動きもあり、Biome とは何か？ で扱っています。
Q. 指摘がゼロになるまで直すべきですか？
種類によります。誤検知が構造的に混ざるので、ゼロを目標にすると無効化が増えて意味が薄れます。新規の指摘を増やさないことを目標にする方が続きます。
Q. 導入したのに誰も見ていません。
量が原因のことが多いです。既存の指摘を全部抱えたまま始めると、最初から数百件出ます。いまの状態を基準線として脇に置き、そこから増えた分だけを見る形にすると回り始めます。
Q. セキュリティの検査としては十分ですか？
十分ではありません。OWASP 自身が、自動で見つけられるのは比較的小さな割合だと書いています。動かして試す検査と、依存しているものの検査と、人のレビューを組み合わせる前提で考えてください。
まとめ
静的解析はコードの形に現れる欠陥を、速く、何度でも、行番号つきで見つける手法です。裏返すと、形に現れないもの、つまり権限の設計や設定側の問題は原理的に見えません。
やることは2つです。誤検知は仕様に近いので、新規の指摘だけを止める運用にする。そして緑を安全と読まず、何を見た検査なのかを添えて報告する。