脆弱性診断エンジニアのフリーランス面談でよく聞かれる質問と答え方

フリーランスの脆弱性診断エンジニアの面談でよく聞かれるのは、どの種類の診断をどこまで手動で担ったか、重大度をどう判定したか、許可と範囲をどう扱ったか、対象に影響が出たときにどう動いたか、報告書をどう書き、どう説明したかの5つです。面談官は、知っている攻撃手法の数より「この人に自社の対象を預けて、安全に、根拠のある結果を返してくれるか」を確かめようとしています。

準備は、模範回答を覚えるより、自分の経験から性質の違う場面を3〜4つ選び、どの質問にもそこから答えられるようにしておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事では診断の面談に固有の質問に絞ります。

診断の面談で面談官が見ていること

診断の面談に出てくるのは、診断の事業者のチームリーダーや、事業会社のセキュリティ部門の担当者であることが多く、本人も診断の経験を持っています。そのため、用語の正しさより、話の中に出てくる確かめ方の順番と、止まるべきところで止まれるかを聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 任せられる範囲：どの種類の診断を、どの工程まで一人で担えるか
2. 安全に作業できるか：許可の範囲を守り、対象に影響が出たときに正しく動けるか
3. 結果の質：判定に根拠があり、相手が直せる報告書を書けるか

診断は、許可がなければ攻撃と同じ操作になる仕事です。そのため、他の技術職の面談より、2の「安全に作業できるか」の比重が大きくなります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「これまで担当した診断の種類と、あなたの役割を教えてください」

確かめたいのは、任せられる範囲です。診断の種類（Webアプリ・API、プラットフォーム、スマートフォンアプリ、クラウドの設定、ペネトレーションテスト）ごとに、経験の期間と、実施・報告書の作成・レビュー・取りまとめのどこまでを担ったかを短く伝えます。

架空の例：「Webアプリ・APIの診断が中心で、手動の確認から報告書まで一人で担当していました。直近の1年は、他のメンバーの報告書のレビューも担っていました。プラットフォーム診断は、外部からの診断の補助の経験があります」

経験の浅い種類は、浅いと正直に伝えるほうが、後の質問との食い違いが起きません。

2. 「ツールの結果と、手動の確認をどう使い分けていますか」

ツールの結果をそのまま報告していないかを確かめる質問です。ツールで広く拾い、手動で認証や権限、業務の流れに沿った不備を確かめる、という組み立てを、具体的な観点の例とともに話します。ツールでは見つけにくい問題を、どんな手順で確かめたかを一つ挙げられると説得力が増します。

3. 「重大度はどのように判定しましたか」

判定に根拠があるかを見ています。CVSSのような評価の枠組みを使った場合は、その使い方だけでなく、対象の業務や公開範囲を踏まえてどう調整したかを話します。発注元と判定が食い違ったときに、どう説明して合意したかの場面があれば、それも良い材料になります。

4. 「誤検知だと判断した例と、その理由を教えてください」

結果を鵜呑みにしないかを確かめる質問です。何を見て誤検知と判断したか、再現をどう試したか、報告書にどう書いたか（書かなかったか）を順に話します。誤検知を取り除く手間を惜しまない姿勢は、報告書の質への信頼につながります。

5. 「診断の範囲や許可は、どのように確かめていましたか」

診断の面談に特有の質問です。作業の前に、承諾した人、対象、期間、時間帯、行わない操作を何で確かめていたかを話します。間に入る会社を通して受けていた場合は、その会社が得た許可の範囲を自分でどう確かめたかまで話せると、慎重さが伝わります。考え方は脆弱性診断エンジニアがフリーランスになるにはで整理しています。

あわせて、範囲の外の依頼が来たときにどうしたかを聞かれることもあります。その場では作業せず、取り決め直してから進めた、という流れを話しましょう。

6. 「診断中に対象の動きがおかしくなったら、どうしますか」

万一のときの動き方を見ています。作業を止める、決めておいた連絡先に伝える、何をした直後に起きたかを記録から示す、再開は相手の判断を待つ、という順番を話します。経験がない場合も、自分ならどう動くかを手順として話せれば十分です。

7. 「報告書で気をつけていることは何ですか」

読み手が直せる報告書を書けるかを確かめる質問です。再現の手順を誰が読んでも追えるようにする、影響を業務の言葉で書く、直し方を具体的に示す、などの工夫を話します。開発者向けと責任者向けで書き分けた経験があれば、それも伝えます。

8. 「報告会で、開発の担当者から反論されたらどう対応しますか」

説明の力と、相手との接し方を見ています。再現の手順を一緒に確かめる、影響の前提を確認する、直し方の選択肢を示す、といった流れを話します。言い負かすより、相手が直す判断をしやすくすることに焦点を当てると、伝わりやすくなります。

9. 「新しい攻撃手法や脆弱性の情報は、どう追っていますか」

学び続けているかを確かめる質問です。公開される注意喚起や基準の更新をどう追い、自分の検証環境で確かめているかを話します。許可のない対象で試したことを話すのは避けてください。

準備は「場面」を3〜4つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：手動で見つけた問題、判定で迷った問題、範囲の外の依頼、報告会でのやり取りなど、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：対象の種類、自分の役割、確かめた手順、判断の理由、相手への伝え方、結果を書き出す
3. 規模の言い方をそろえる：対象の種類、画面やホストの数の目安、期間を、どの場面でも同じ言い方で話せるようにする
4. 2分版と5分版をつくる：最初は短く話し、掘り下げられたら手順まで話せるようにする
5. スキルシートと照らし合わせる：シートに書いた種類・役割・手動の範囲と、話の内容が一致しているかを確かめる

面談官はスキルシートを見ながら質問するため、話とシートがずれると信用されにくくなります。シートの書き方は脆弱性診断エンジニアのスキルシートの記事、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

面談の相手によって重心が変わる

診断の事業者のチームに加わる案件では、手順や報告書の型が決まっていることが多く、それに合わせられるかが見られます。事業会社の内製の診断を支える案件では、診断そのものより、社内の開発チームに伝え、直してもらう力の比重が大きくなります。

診断の案件ならではの逆質問

逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。診断の案件では、次の点を聞いておくと判断がしやすくなります。

• 担当する対象の種類と、1件あたりの診断の期間の目安
• 作業してよい時間帯と、夜間・休日の作業の有無
• 診断元（端末・回線）を誰が用意するか
• 報告書の型と、レビューを誰が行うか
• 許可の書面を誰が取り、作業者にどう共有されるか
• 対象に影響が出たときの連絡先と手順

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。ここで聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点は脆弱性診断エンジニアの案件の選び方で整理しています。

よくある質問

実際に見つけた脆弱性の例を、具体的に話してもよいですか？

対象や発注元が特定されない形に一般化すれば、種類と確かめ方の流れを話すのは問題ないことが多いです。社名、システムの名前、まだ直っていない可能性のある箇所は話さないでください。守秘義務の範囲に迷う場合は、話さない側に倒すほうが安全です。

ペネトレーションテストの経験がなくても、診断の案件に入れますか？

入れます。多くの診断案件は、Webアプリ・APIやプラットフォームの診断が中心です。面談では、経験のある種類で一人で担える工程をはっきり伝え、ペネトレーションテストは補助の経験や学習の状況を正直に話しましょう。

オンラインの面談で、画面を見せながら説明を求められることはありますか？

案件によっては、自分で用意した練習環境の画面や、架空の内容で書いた報告書の見本を使って説明を求められることがあります。実際の案件の報告書を見せるのは避けてください。オンライン面談の準備はオンライン面談の記事で解説しています。