Web脆弱性の基礎知識（最終回）：脆弱性を知ることから、安全に運用することへ

これまでの3回は目録でした。データがコマンドと誤解される問題、認可と設定の不備、設計とビジネスロジックの欠陥です。しかし病名を知るだけで健康にはなりません。同じ OWASP の資料を読んだ2つのチームの違いは、一方が原則を毎スプリント繰り返す手順に変えたのに対し、もう一方がセキュリティをリリース前のチェック項目のままにしている点にあります。

最終回のテーマはプロセスです。開発ライフサイクルのどこにセキュリティを置くか、どのツールをどの工程で使うか、誰が何を担うか、どれだけの期限で修正すると約束するか、そして実際に事故が起きた日に何をするかを扱います。

1. セキュリティは工程ではなく、ライフサイクルを貫く層

定着させる近道は、新しいプロセスを作るのではなく既存の工程に紐づけることです。要件の精緻化では「この機能はどのデータに触れ、誰に何を許すのか」を問う。設計では機微なフローに1時間の脅威モデリングを充てる。実装では自作より実績あるライブラリを使い、レビュー観点に数行のセキュリティ項目を足す。マージ時は機械に反復的なスキャンを任せる。リリース前に設定と秘密情報を確認し、本番後は監視と対応体制を保つ。

「シフトレフト」は正しい助言ですが、「最初にやれば終わり」と誤読されがちです。もう半分はシフトライトであり、重大な脆弱性の多くは稼働後にログ、アラート、利用者、あるいは善意の研究者からの連絡によって見つかります。

2. ツール群：どれも真実の一部しか見えない

1つのツールで全部を賄うことはできません。静的解析は文字列連結クエリのような危険なパターンに強い一方、誤検知が多い。依存関係スキャンは安価でサプライチェーンのリスクを捉えるため、最初に有効化する価値があります。動的スキャンは稼働中のアプリを攻撃し、設定や実行時にだけ現れる問題を見つけます。シークレットスキャンは API キーの混入を防ぎ、差分だけでなくコミット履歴も対象にする必要があります。IaC スキャンは、公開バケットや広すぎるセキュリティグループが実在する前に検出します。

無効化されないゲートの作り方

すべてを止めるゲートは2週間で外されます。持続する運用は、修正版が存在する Critical と High のみマージをブロックし、残りは担当者と期限のあるバックログへ回すことです。最初の1か月で誤検知を丁寧に減らしてください。誤ったアラートの行列は、警告を無視する習慣をチームに教えてしまいます。そして結果は四半期に一度開くダッシュボードではなく、開発者がいるプルリクエストの中に表示されるべきです。

3. セキュリティ専門家でなくても QA にできること

できることは多くあります。正常系の隣に悪用ケースを足しましょう。低権限アカウントで高権限 API を直接呼ぶ、URL の識別子を他人のレコードに変える、項目の欠落・余剰・型違いを送る、あらゆる入力欄に極端に長い文字列や特殊文字を入れる、送信ボタンを高速に連打する、多段フローを逆走する、画面ではなく API の生レスポンスを確認する。テスト後にはログを読み、パスワードやトークン、個人データが書き出されていないか確かめます。必要なのは資格ではなく、「自分が善良でなければこの画面で何を試すか」と問う習慣です。

4. ペネトレーションテスト、届出窓口、バグバウンティ

ペネトレーションテストは基礎が整ってから価値を生みます。そうでなければ、無料ツールでも見つかるものを専門家に高額で指摘してもらうことになります。明確なスコープ、全ロール分のアカウント、API ドキュメント、本番に近い環境を用意しましょう。報告を受けたら、実証された経路だけでなく根本原因を修正し、同じ欠陥が他に何箇所あるかを確認し、再テストを依頼します。

並行して、外部からの報告窓口を公開してください。メールアドレスやドメイン上の security.txt に加え、返答することと善意の報告者を追及しないことを明記します。脆弱性を見つけた人が送り先を見つけられず、数か月を失う組織は珍しくありません。バグバウンティはその次の段階です。

5. 脆弱性管理：データで優先し、期限で修正する

指摘の一覧は常にチームの処理能力より長いため、本当の問いは「どれを先に直すか」です。CVSS は理論上の深刻度を示しますが、実際に悪用される可能性と、自社システムの露出度を併せて見る必要があります。社内ツールだけが使うライブラリの高スコアの問題より、公開エクスプロイトが存在するインターネット公開サービスの中スコアの問題のほうが危険です。

深刻度ごとの修正期限を明示し、善意ではなくプロセスに組み込みます。Critical は数日、High は数週間、Medium は次のリリース列車で。それを現実的にするには、依存関係更新を小さく頻繁なプルリクエストへ自動化し、バージョンを上げられるだけの信頼できるテストを持ち、資産目録と SBOM を維持することです。大きな脆弱性が公表されたとき、「そのライブラリを使っているか、どこで使っているか」に1時間で答えられるかどうかが分かれ目になります。

6. 監視とインシデント対応

事故を永久に避けられるチームはありません。違いは、5分で気づくか5か月後に気づくかです。警告すべき兆候は地味なものです。特定アカウントからの認可拒否の急増、失敗の連続直後に見知らぬ場所から成功したログイン、エクスポート系エンドポイントへの異常なトラフィック、深夜に跳ね上がるインフラ費用など。

悪い日のための短いランブックを用意してください。午前3時の当番が従える具体さで、指揮者は誰か、影響範囲をどう隔離するか、何かを再起動する前に証拠をどう保全するか、漏れた可能性のある鍵とトークンをどう失効させるか、復旧宣言の基準は何か、顧客と規制当局への通知は誰の責任か。通知は礼儀の問題ではありません。ベトナムを含む多くの国の個人データ保護法は、報告の義務と期限を定めています。火事の最中に調べるのではなく、事前に法務と確認しておきましょう。

事後には非難を目的としない振り返りを行います。目的は、どの仕組みと手順が誤りを許したかを見つけ、学びを新しいテスト、新しいアラート、より安全な既定値という具体物に変えることです。

7. 人と計測

強制されたセキュリティはうまく機能しません。多くの企業で機能するのは、チームごとにセキュリティチャンピオンを置く形です。脅威モデリングを促し、スキャン結果を仕分け、全社の担当者とつなぐ役割を、関心のあるエンジニアが担います。加えて、自社製品の実際の不具合を題材にした短い勉強会は、年1回4時間の研修よりはるかに効果的です。

計測は能力を映す少数の指標に絞ります。発見から修正までの平均時間、認可の自動テストで覆われた機微エンドポイントの割合、月あたりリポジトリで検出された秘密情報の件数、SBOM が最新である割合、事故の発生から人が気づくまでの時間。これらは改善できますが、アラートの総数は何も語りません。

8. 小さなチーム・小さな予算で先にやること

• 管理者・インフラ・ソース管理のアカウントすべてに多要素認証を有効化する。
• 秘密情報をリポジトリと設定ファイルから出し、シークレットマネージャーへ移す。
• CI で依存関係スキャンとシークレットスキャンを有効化し、Critical をブロックする。
• クラウドストレージと管理画面の公開範囲を棚卸しする。
• 最も機微なエンドポイントに認可の自動テストを書く。
• 定期バックアップを取り、少なくとも一度は実際に復元を試す。
• ログを集約し、意味のあるアラートを3〜5個と当番を定める。
• 外部からの脆弱性報告窓口を公開する。

シリーズのまとめ

第1回：データとコマンドを分離すること。第2回：権限と設定はサーバー側で、既定は拒否で決めること。第3回：最も高くつく欠陥はエディタではなく設計会議で生まれること。第4回：以上のすべては、繰り返せて、測れて、担当者がいて初めて意味を持つこと。

完全に安全なシステムは存在せず、それは目標でもありません。目標は、攻撃の費用を見返りより高くすること、そして被害が広がる速度よりも速く検知し封じ込められるチームになることです。それは壁に飾る証明書ではなく、毎スプリント繰り返される習慣です。

参考文献

• OWASP Top 10:2025 — owasp.org/Top10/2025
• OWASP Application Security Verification Standard — owasp.org/www-project-application-security-verification-standard
• OWASP SAMM — owaspsamm.org
• NIST SP 800-61 — csrc.nist.gov
• FIRST EPSS — first.org/epss