読むだけでは、分からないこと

sec-logic で見た価格改ざんの穴を思い出してください。total = price * qty というコードだけを見ても、「この price がクライアントから来てよいものか」は、コードの外側(このアプリが何を売っていて、価格をどう決めるべきか)を知らないと判断できません。
「この変数は、どこから来るべきが正しいのか」は、アプリの仕様という、コードの外にある知識が要ります。sec-authz・sec-logic で「ツールが原理的に見つけられない」と学んだのと、同じ理由です——人間の目でも、仕様を知らなければ判断を誤ります。

前章の x-staff-role ヘッダーが、まさにこれです。このコード単体を読んでも、「本番環境で、このヘッダーが外部から上書き不可能か」は分かりません。リバースプロキシの設定、ネットワーク構成、デプロイの仕方——コードの外にある前提を確認して、初めて結論が出ます。
ソースコード診断の報告書に「〜という前提であれば安全ですが、その前提を実機で確認してください」と書くのは、逃げではなく誠実さです。断定できないことを、断定しない。

sec-csp で学んだ CSP のように、アプリのコードそのものではなく、配信設定(ヘッダー)で効いている保護があります。ソースコードのリポジトリだけを見ていると、こうしたコードの外側の防御層を見落とします。実際の診断では、デプロイ設定・インフラ構成も含めて確認する必要があります。

ここまでのコースの多くは、ブラックボックス(動かして攻撃する)診断でした。このコースはホワイトボックス(読む)診断です。どちらか一方が優れているのではなく、補い合う関係にあります。
ホワイトボックスが強いところ——実行が難しい経路(エラー処理・バッチ処理)にも届く、根本原因まで正確に指摘できる。
ブラックボックスが強いところ——実行環境の前提込みで、実際に動くかを確定的に確認できる。
実務の診断は、しばしば両方を組み合わせます——コードを読んで疑わしい箇所に当たりをつけ(ホワイトボックス)、実際に動かして確定させる(ブラックボックス)。sec-audit の演習で見つけた「疑わしい箇所」は、旗艦コースで培った攻撃の手で、実機で確かめて初めて結論になります。

実務では、grep で sink を探す作業を、静的解析ツール(SAST)が自動化してくれます。パターンマッチで危険な関数呼び出しを一覧にする、という部分は機械が得意です。でも、「この経路は本当に無害化されているか」「このビジネスロジックは正しいか」という最終判断は、依然として人間の仕事です。ツールは、あなたが読む範囲を絞る助手であって、代わりに読んでくれるわけではありません。