ローンチまで3週間、ペネトレーションテストはまだ

ある香港のスタートアップは、セキュリティテストの予算を決める前に、ローンチ日を決めてしまった。ローンチまで残り3週間になって、ようやく誰かが「これ、ペネトレーションテストはやったの？」と尋ねた——遅すぎて、その質問自体が、まだどんな種類のテストが可能かを決めてしまうほどだった。 これは実在の顧客ではなく、Brocentがよく目にするパターンをもとにした複合シナリオである。すなわち、セキュリティテストが最初からローンチ日を基準に計画されるのではなく、「残り時間がどれだけあるか」で範囲が決められてしまうというパターンだ。

この業界：まず出荷、テストは後回し

香港のテック・SaaS業界は、圧縮されたスケジュールで動いている。シードやシリーズAの資金調達がもたらす資金繰りの余裕は、年単位ではなく月単位で測られる。公開ローンチ日は早い段階で決められることが多く——本番ビルドの最初の1行が書かれる前に、プレスや投資家、あるいは順番待ちリストに対してすでに発表されていることさえある——なぜなら、取締役会にとってロードマップを現実味あるものにするのは、まさに「日付」だからだ。エンジニアリングチームはその日付から逆算して作業を進め、開発初期に存在していた余裕は、最終的にどこかで吸収されてしまう。遅れる連携機能、作り直されるオンボーディングフロー、決済代行会社側の審査待ちなど。

セキュリティテストは、カレンダー上で特別に時間を確保される項目になることはめったにない。創業者がセキュリティを軽視しているからではない——直接尋ねれば、たいていの人はむしろその逆を口にする——そうではなく、ローンチ日は対外的なマーケティングと投資家への約束であるのに対し、「いつこれをテストするか」は外部の締め切りを持たない社内のエンジニアリング判断であり、誰かがその質問を会議の場で口に出すまでは、そのまま放置されがちだからだ。初めて、あるいは最も重要な形で顧客向けにリリースされる製品——実際に顧客のアカウント、決済情報、業務データを初めて保持するアプリケーション——について言えば、その質問はたいてい誰もが望んでいたよりも遅く、そして答えが安心できるものになる時点よりもさらに遅れてやってくる。

これは一社だけの特殊な話ではない。香港のテック・SaaS企業の間で、特定の、見覚えのある瞬間として繰り返し現れる。製品は機能面では完成しており、ローンチ日は確定して対外的に発表済み、そこで誰か——技術に明るい共同創業者、セキュリティ意識の高い新しい採用メンバー、投資家のデューデリジェンスでの質問、あるいはエンタープライズ見込み客の調達チェックリストの一項目——が、そのアプリケーションが実際に破ろうとする試みにさらされたことがあるのか、それとも単に既知のシグネチャを照合するツールでスキャンされただけなのかを尋ねる。

シナリオ：セキュリティ準備ではなくマーケティングが決めたローンチ日

香港のテック企業を思い浮かべてほしい——エンジニアは十数名ほど、製品はほぼ1年にわたり積極的に開発が続けられ、ローンチ日はおよそ2カ月前に決められ、以来プレスリリース、パートナー発表、そして自社のランディングページ上のカウントダウンにまで組み込まれている。プロダクト自体の構築は、多くのローンチ前製品と同じく速いペースで進んできた。機能は次のデモをアンロックする順番で出荷され、決済連携は最終スプリントで急いで組み込まれ、テスト用に誰かが必要としたまま削除されずに残っている管理画面や社内ツール向けのルートもいくつか存在する。

ローンチまで残り3週間、日常のエンジニアリングスタンドアップで、誰か——たいていは部屋の中で最もセキュリティ意識の高い人物であり、必ずしも専任のセキュリティ担当者とは限らない——が、静かに「答えは出ているもの」と前提されていた質問を口にする。「これ、実際にペネトレーションテストはやったんだっけ？」正直な答えは、たいてい、開発のどこかの段階でチームが自動脆弱性スキャンを一度実行し、まあまあきれいに見えるスキャン結果を安心材料として扱い、それ以上は何も予約していない、というものだ。人手によるテストの範囲を定めた者はおらず、カレンダーに載せた者もいない。それは、必要な判断として一度も俎上に載ったことがなかっただけなのだ——この瞬間までは。

この後に何が起こるかが、残りの3週間が実際にどれだけの価値を持つかを大きく左右する。すぐにテストを予約したチームには、まだ意味のある範囲を定める時間が残っている——外部ネットワークテスト、顧客向けWebアプリケーション、そして何より重要な認証・決済フローだ。そして決定的に重要なのは、発見された問題を公開ローンチ前に修正し、再テストする時間も残っているという点である。テストが本当に必要かを議論したり、見積もりを比較したり、「既存の脆弱性スキャンで十分ではないか」と議論したりして1週間を費やすチームは、まさに本物のテストを可能にしていたはずのその余裕そのものを使い果たしてしまう。ここで本当に重要な時計は、ローンチまでの3週間ではなく、テストを実施すると実際に決断した瞬間から数えて、あと何日残っているかである。

これが引き起こす現実の問題

固定されたローンチスケジュールの終盤に届くペネトレーションテストの依頼は、特定の、繰り返し起こる一連の問題を生み出す——テストの方法論そのものが変わるからではなく、その周囲の制約が変わるからだ。

• 残された時間の中で、見せかけではない意味のあるテスト範囲を定めること。 外部・内部・Webアプリケーションを網羅する完全なエンゲージメントは、それだけで通常2〜3週間を要する。ローンチ前に残されたわずかな日数に圧縮されると、チームは正直に範囲を絞り込むか——実際に顧客向けで、インターネットに露出している部分、つまり攻撃者が初日に到達できる部分にテストを集中させるか——あるいは、紙の上では網羅的に見えても、発見結果に対応する時間をまったく残さないテストを発注してしまうリスクを負うかのどちらかになる。ローンチ前に誰も読む時間のないレポートは、コンプライアンス上の記録にはなっても、セキュリティ対策にはならない。
• 脆弱性スキャンとペネトレーションテストを混同すること。 この二つは本当に異なる作業であり、混同されがちなのは、両者ともに非専門家が同じように読み取ってしまう「クリーン」か「クリーンでない」かというシグナルを出すからにほかならない。脆弱性スキャンは自動化されており、広範囲かつ反復可能だ——シグネチャベースのツールを使って広い範囲の資産を既知の弱点についてチェックし、大規模に明白な、未パッチの、あるいは設定ミスの問題を捉えるのに非常に優れている。しかしそれは実際に何かを悪用しようとしたり、発見結果を連鎖させたり、攻撃者が侵入後に実際に到達できる範囲を示したりすることはない。ペネトレーションテストはそこに人間を加える——認定を受けたテスターが実際に侵入し、権限を昇格させ、本物の攻撃者と同じように実際の影響を証明しようと試みるのだ。数カ月前にスキャンを実行し、それを「テスト済み」だと考えているチームは、ローンチ前のセキュリティレビューが実際に尋ねている質問とは、違う質問に答えていることになる。
• 発見結果がローンチ前ではなく、ローンチ後に表面化すること。 これはあらゆる駆け込みのローンチ前テストが避けようとしているまさにそのシナリオであり、遅すぎるテスト依頼がそれをより起こりやすくしてしまうシナリオでもある。ローンチの1週間後——実際の顧客がすでにアカウントを持ち、決済データが流れ始めている段階——に発見される重大な問題は、ローンチの1週間前に発見される同じ問題よりも、実質的にはるかに悪い問題となる。脆弱性そのものが変化したわけではなく、被害の及ぶ範囲が変わってしまうからだ。
• 顧客が製品を使い始める前に、確立された修正期間が存在しないこと。 問題を発見することは、作業全体の半分にすぎない。問題を修正し、その修正が実際に穴をふさいだことを確認するのが、もう半分だ。ローンチ前にほとんど余裕を残さずに予約されたテストは、そのどちらの時間も残さない——発見レポートは、製品がすでに公開された後になって、チームが初めて目にするものになってしまい、そもそもローンチ前にテストする理由の大部分を無にしてしまう。

これらはいずれも、そのチームの評価を下げるものではない——決済連携やアプリストアの審査待ちが固定的な入力条件として扱われるのと同様に、セキュリティテストを「ローンチ前のどこかで時間を見つけてやる」タスクとして扱い、ローンチ日そのものと同じように計画に固定的に組み込まないことの、当然予想できる帰結にすぎない。

Brocentの見解：テストはローンチ日を基準に計画するもので、その周りに押し込むものではない

Brocentがここで採用している原則は、言葉にすれば単純だが、締め切りのプレッシャーの下では見落とされやすい。ペネトレーションテストは、ローンチのための他のすべてのタスクがカレンダーの取り分を確保し終えた後に残ったわずかな隙間に押し込むのではなく、ローンチ日を基準に計画されるべきだということだ。つまり「いつテストするか」は、ローンチ日そのものが決まるのと同時に決めるべき判断であり、残り3週間になってから、あるいは理想を言えば、製品が機能的に完成してからさらに3週間経ってから考えるべきものではない。テスト、発見結果、そして本物の修正期間のすべてが、ローンチ前に無理なく収まるだけの早さで決めておくべきなのだ。

とはいえ、「もう残り3週間しかない」ことはテストを省略する理由にはならない——それは範囲を定める上での制約であり、正当な制約である。ローンチ前1週間で行われる、範囲を絞り、時間を区切ったテストであっても、範囲の選択が「限られた時間の中で何が達成可能か」を正直に反映したものである限り、まったくテストをしないよりもはるかに意味がある。外部とWebアプリケーションに絞り込んだ、利用可能な時間内に収まるテストは、たとえ短くとも優先順位づけされた修正期間があれば、製品が実際の顧客に向けて公開される最初の数日間で重要となる、最も深刻で悪用されやすい問題を捉えることができる。これは、十分なリードタイムを持って計画された完全なエンゲージメントと同じ深さの保証ではない——Brocentは両者を同等だとは提示しない——しかし、古い脆弱性スキャンだけを頼りにローンチするのに比べれば、実質的にはるかに良い立場である。

より根本的なポイント、そしてBrocentがこの状況にあるすべてのチームに伝えていることは、テストをローンチ日に対して早く予約すればするほど、実際に変えられることが増えるという点だ。6週間の余裕を持って予約されたテストであれば、外部・内部・Webアプリケーションの範囲を完全にカバーし、本物の修正時間を確保し、修正が実際に穴をふさいだことを確認する再テストをローンチ前に行うことができる。6日間の余裕しかなくても、実際の顧客より先に最も重要な問題を発見することはできる——ただし、選択できる幅はカレンダーが縮むのと同じ速さで狭まっていく。どちらの極端も、パニックになる理由にも、テストを省略する理由にもならない。むしろどちらも、テストするかどうかの判断は、3週間前のスタンドアップで誰かが不意に持ち出した質問への反応としてではなく、カレンダー上の本物の日付を基準に、早い段階で、意識的に下されるべきだということを物語っている。

実務ではどのような形になるか

初めて、あるいは最も重要な形で顧客向けローンチを迎えようとしている香港のテック・SaaS企業にとって、実際に役立つペネトレーションテストは——6週間の余裕があろうと、6日間の余裕しかなかろうと——たいてい同じ形をしている。

実際に出荷される内容に範囲を絞ったアプリケーション層・インフラ層のテスト。 ローンチ前のほとんどの製品にとって、これは顧客向けWebアプリケーションをOWASP Top 10に分類される問題——インジェクション系の脆弱性、認証の不備、安全でない直接オブジェクト参照、アクセス制御の欠陥、セキュリティ設定ミス——に対してテストすることを意味し、同時にそのアプリケーションが依拠する外部ネットワーク境界、すなわちファイアウォール、リモートアクセス拠点、外部の攻撃者がまず到達するインターネット露出インフラも対象に含む。スケジュールが許せば、内部ネットワークテストを追加し、初期の足がかりを得た攻撃者がどこまで横展開できるかを検証し、ソーシャルエンジニアリングやフィッシングシミュレーションテストで人的層を別途評価する。Brocentのペネトレーションテストサービスは、外部・内部・Webアプリケーション・ソーシャルエンジニアリングの4つの範囲すべてを、クローズドボックス（事前情報なし、本物の外部攻撃者を模擬）またはオープンボックス（限られた時間枠でテストの深さを最大化するため、テスターにアーキテクチャの詳細を提供）のいずれかで実施しており、範囲をカレンダーが実際に許容する量に正直に合わせることができる。

抽象的な深刻度だけでなく、実際の悪用可能性を基準に優先順位づけされたレポート。 すべての技術的問題を同じ重みで列挙した発見レポートは、ローンチまで数週間ではなく数日しか残っていないチームにとって役に立たない。重要なのは、どの発見が本当に悪用可能なのか、どれが実際に到達された場合に本物の事業インパクトをもたらすのか、そしてどれがローンチ後のパッチサイクルまで待っても合理的に問題ないのかを、平易な言葉でチームに伝えるレポートだ。Brocentのレポートは、CVSSスコアと概念実証の証拠、そして事業インパクトの文脈を伴っており、それはまさに小規模なチームが1週間ではなく1日の午後でトリアージを終え、エグゼクティブサマリーを読んで本当に緊急なものを理解し、正しい優先順位で修正に着手できるようにするためのものである。

ローンチ前に収まる「修正して再テストする」ループ。 ローンチの3日前に問題を発見しても、顧客がその製品に触れる前に修正が実際に機能したことを確認する仕組みがなければ、その発見は役に立たない。だからこそBrocentは、ペネトレーションテストのパッケージを再テストを中心に設計している——完全な2回目のエンゲージメントではなく、修正後にフラグの立った発見結果だけを対象とした確認パスだ。圧縮されたローンチ前スケジュールにおいて、この再テストはプロセス全体の中で最も価値のある数時間になることが多い。「直ったと思う」と「直ったことを確認した」の違いであり、実際の顧客データが危険にさらされる段階になれば、この違いは非常に大きな意味を持つ。

これらはいずれも、チームが早くから始めていなければ本当の価値を得られないというものではない。求められるのは、テストの範囲を、完全に省略するか、誰も対応する時間のない形式的な作業にするかのどちらかにするのではなく、実際に残された時間に対して正直に定めることだけである。

これがどこに位置づけられるか：一度きりの駆け込みではなく、継続的なセキュリティ態勢の一部としてのテスト

一度のペネトレーションテスト——たとえ十分なリードタイムと明快な修正期間を持って適切に範囲設定されたものであっても——答えるのは一つの質問だけだ。すなわち、この日付でテストされたこのアプリケーションは、重要な意味において悪用可能かどうか。成長中の企業が継続的に答えを必要としている質問には答えていない。誰がセキュリティテストを継続的な実務として担うのか、誰が前回のテストの発見結果が実際に修正されたかを追跡するのか、そしてコードベースが前回のカバー範囲がすでに陳腐化してしまうほど乖離してしまう前に、誰が次のテストが確実に実施されるようにするのか。一度きりのエンゲージメントは、どれほど優れていても、それ単独ではこの問いに答えることができない。そして、ローンチ日がその問いを浮かび上がらせたときにしかテストしないチームは、次の大きなリリース、次のエンタープライズ顧客からのセキュリティ質問票、あるいは次の資金調達ラウンドのデューデリジェンスの際に、まったく同じシナリオに再び陥ることになりやすい。

これこそがBrocentのマネージドプランが埋めようとしているギャップである。セキュリティテストは、重要になるたびに締め切りのプレッシャーの下で再発見される消防訓練であることをやめ、成長中のチームがすでに持っている継続的なカバー範囲の一部となる——プランに含まれる他のマネージドセキュリティサービスと並んで、範囲を定め、スケジュールに組み込み、継続的に追跡されるものになり、ローンチ週の締め切りのたびにゼロから交渉し直すものではなくなる。プランに加入しているチームは、ローンチ日の3週間前になって「今回は誰にペネトレーションテストを頼めばいいのか」と自問することはない。その関係性、範囲についての会話、そして再テストのリズムはすでに存在しており、まさにそれが「決まった日までにこれをテストしてもらう必要がある」を、慌ただしい対応から単なるスケジュール調整の会話へと変えている。

ペネトレーションテストそのもの——ここまで説明してきた作業内容——は、引き続き独立して範囲を定められるサービスとして提供されている。すでに堅実なテスト習慣を築いており、自社の防御側が実際の侵入をきちんと検知し、阻止できるかどうかを測りたいチームにとっては、レッドチームエンゲージメント（Red Team Engagement）がその次のステップとなる。これは、範囲を明確に定めた脆弱性探索ではなく、非公開かつ目的志向のアドバーサリー・シミュレーションである。どちらも本物の、独立したサービスであり、それぞれ独自の範囲とコストを持つ。しかし、あらゆるローンチ日を新たなセキュリティの一発勝負として扱うのをやめたいと考えている、成長中の香港のテック企業にとって、より役に立つ問いは「今回はどの一度きりのテストを予約するか」ではなく、セキュリティテスト、修正の追跡、そして次のエンゲージメントを迅速に範囲設定できるようにする関係性そのものが、すでに残りの技術スタックをカバーしているマネージドプランの中に収まるべきではないか、という問いである。プランの各ティアは料金ページで確認でき、あるいはBrocentに相談して、今週予約するにせよ、6週間後に予約するにせよ、ローンチ前テストが実際にどこに位置づけられるかを話し合うこともできる。

よくある質問

ローンチのどれくらい前にペネトレーションテストを予約すべきか

理想を言えば、ローンチ日そのものが決まるのと同時に、できるだけ早く。外部・内部・Webアプリケーションを含む完全なエンゲージメントは通常2〜3週間を要し、これには修正時間と再テストの時間は含まれていない。ローンチ前に4〜6週間の余裕を持って予約すれば、完全な範囲、本物の修正期間、そして修正が機能したことの確認のための余地が生まれる——これこそが、出荷される内容そのものを変えるテストと、すでに出荷された内容を単に記録するだけのテストとの違いである。

ペネトレーションテストと脆弱性スキャンの違いは何か

脆弱性スキャンは自動化されており、広範囲をカバーする——シグネチャベースの既知の弱点について、幅広い資産を迅速かつ反復的にチェックし、定期的なペースで実行するのに適している。ペネトレーションテストは、認定を受けた人間のテスターを加え、スキャンが検出できるだけの問題を実際に悪用しようと試み、本物の攻撃者と同じように複数の発見を連鎖させ、潜在的な問題のリストではなく実際の事業インパクトを示す。多くの組織は両方を活用している——定期的なペースでのスキャンと、ローンチ、年次点検、あるいは特定のコンプライアンスや顧客要件のための人手によるペネトレーションテストだ。クリーンなスキャン結果は、人手によるテストも同様にクリーンな結果になるという証拠にはならない。

香港でペネトレーションテストを実施すると費用はどれくらいか

範囲によって大きく異なる。香港市場でコンサルタントが実施する人手によるペネトレーションテストは、一般的に約5,000米ドルから、含まれる範囲（外部、内部、Webアプリケーション、ソーシャルエンジニアリング）の数と環境の規模に応じて、数万米ドルに及ぶこともある。Brocent自身の範囲設定されたエンゲージメントは3,500米ドルからで、最終的な見積もりは提案段階で合意された具体的な範囲によって決まる——単一のローンチ前製品に対する外部とWebアプリケーションに絞ったテストと、より大規模な環境に対する4つの範囲すべてを含む完全なエンゲージメントとでは、価格が異なる。

ペネトレーションテストは2週間で完了できるか

範囲を適切に定めれば可能である。外部・内部・Webアプリケーションを含む完全なエンゲージメントは、それだけで通常2〜3週間を要し、厳格な2週間のローンチ前ウィンドウの中では修正の余地がほとんど、あるいはまったく残らない。外部境界と顧客向けWebアプリケーション、すなわち初日に最もさらされる部分に絞り込んだテストであれば、2週間以内に収めることができ、それでもローンチ前に短い修正期間を残すことができる。正直に言えば、ここでのトレードオフはカバー範囲だ。2週間のウィンドウは絞り込んだ範囲をうまくサポートできるが、6週間のエンゲージメントと同じ深さはサポートできない。

ローンチ直前のテストで重大な問題が見つかったらどうなるか

その発見は、生の深刻度ラベルではなく、レポートに含まれるCVSSスコアと証拠に基づく詳細情報を使って、悪用可能性と事業インパクトに照らして直ちにトリアージされる。本当に重大で、容易に悪用できる問題については、正直な選択肢は次の二つである。残りのスケジュールが許すのであれば、ローンチ前に修正して再テストするか、あるいは影響を受ける特定の機能やフローのローンチだけを延期し、残りは予定通り出荷する。公開ローンチの数日前にこうした会話をするのは決して気楽ではないが、顧客より先にそれを発見することこそが、ローンチ後ではなくローンチ前にテストする理由そのものである。

すでに脆弱性スキャンをやっているなら、ペネトレーションテストは必要か

一般的には必要である。特に初めて、あるいは最も重要な形で顧客向けにリリースする場合はなおさらだ。スキャンは有用で反復可能なベースラインであり——既知の、シグネチャベースの問題を効率的に捉える——しかし、実際に悪用を試みたり、発見を連鎖させたり、人手によるテストのように実際の影響を示したりすることはない。クリーンなスキャン結果が答えるのは「自動化ツールで既知の弱点が見つかったかどうか」であり、「本気で取り組めば誰かが実際に侵入できるかどうか」ではない。顧客のアカウントや決済データを初めて保持することになるローンチについて言えば、これはローンチ後ではなく前に答えておく価値のある、実質的に異なる問いである。

レッドチームエンゲージメントとペネトレーションテストは同じものか

いいえ——両者は異なる問いに答えるものだ。ペネトレーションテストは「この明確に定義されたシステム群にどのような脆弱性が存在するか」を問い、通常は事前に社内チームに開示され、スケジュールが調整され、通常は数日から数週間で完了する。レッドチームエンゲージメントはまったく異なる問いを立てる——「攻撃者は特定の目標に到達できるか、そして我々はそれに気づくか」。これは、社内の小さな連絡担当者を除いて非公開のまま実施され、脆弱性の存在ではなく検知と対応能力をテストするもので、通常は数週間から数カ月を要する。レッドチーミングは一般的に、機能しているペネトレーションテストのプログラムがすでに存在していることを前提としている——基礎的なセキュリティ衛生が整った後の次のステップであって、ローンチ前テストそのものの代替ではない。

何もしない場合 vs. 駆け込みのテスト vs. ローンチ日を基準に計画されたテスト

この3つのアプローチの違いは、実際にはテストの方法論そのものにあるのではない——同じ認定テスター、同じ技術、同じレポート基準がすべてに適用される。違うのは、テストするという判断がいつ下されるか、そして発見結果が出た後にカレンダー上でどれだけの時間が対応に残っているかである。

何もしない（「問題はローンチ後に直せばいい」）

• アプリケーションが本物の侵入試行に耐えられるかどうかを独立して検証する手段が一切ない——あるのは、実施されたとしても自動スキャンがたまたま捉えたものだけだ。
• 重大な問題は、顧客アカウントとデータがすでに公開された後になって、実際のユーザーか、あるいは攻撃者によって発見される——最悪の発見にとって、最悪のタイミングである。
• 露出が始まる前の修正期間は存在しない。なぜなら、何かが発見される頃には、露出はすでに始まっているからだ。

ローンチ直前1週間の駆け込みテスト（一定のカバー範囲はあるが、修正の時間がない）

• テストは実際に行われ、それでも本当に深刻で悪用されやすい問題を捉えることはできる——まったくテストしないよりは、はるかに良い。
• 範囲は時間的プレッシャーの下で、多くの場合は意図的ではなく非公式に絞り込まれ、実際にテストされる内容に抜け漏れが生じる可能性がある。
• 発見結果は、ローンチ前に修正して再テストする時間がほとんど、あるいはまったくない状態で出てくることが多く、そのレポートはローンチ前の改善を促すものではなく、ローンチ時点で既知だったリスクの記録になってしまう。

ローンチ日を基準に予約され、修正期間を確保した範囲設定テスト（Brocentのモデル）

• 範囲は利用可能な時間に対して意図的に選ばれる——圧縮されたスケジュールでは正直に絞り込み、リードタイムが許せばより広くカバーする——省略するか無理に薄く引き伸ばすかのどちらかにはしない。
• 実際の悪用可能性と事業インパクトを基準に優先順位づけされた発見レポートにより、小規模なチームでも迅速にトリアージし、本当に重要なことから対応できる。
• ローンチ前に修正を確認する「修正して再テストする」サイクルにより、「直ったと思う」を「直ったことを確認した」に変え、その答えに対してまだ行動できる時間があるうちに確認を終える。