ペンテスターは敵か？開発者が語るペンテストと静的解析結果への本音

開発者が本来の姿を見せるのは、締め切りに追われながら素晴らしい機能を実装しようと、深く集中している時です。機能開発は私たちにとって最もやりがいのある仕事であり、ソフトウェア開発ライフサイクル（SDLC）における根本的な成果物でもあります。

しかし、以前にも触れたように、多くの開発者は依然としてセキュリティのベストプラクティスよりも機能を優先しています。結局のところ、多くの組織ではセキュリティは「誰か他の人の仕事」とされており、私たちに対する十分なセキュリティ教育も不足しているのが現状です。ペネトレーションテストや静的解析ツール（SAST）は、セキュリティリスクを軽減するプロセスの一部に過ぎず、私たちの業務とは独立して行われます。もちろん、修正のためにコードが差し戻されてくるまでは。

そんな時、多くの開発者はこう思うのです。「ペネトレーションテスターは私のことが嫌いなのか？」と。

こうしたやり取りが、チームや組織の文化を形作ります。懸念すべきは、コミュニケーションや相互理解、協力体制の欠如が、少なくとも開発者側に緊張感を生んでいるという点です。想像してみてください。何百時間もかけて素晴らしい彫像を彫り上げたのに、誰かがやってきて「土台がなっていない」と言い放ち、ハンマーで彫像を壊し始めたらどう思うでしょうか。テスターと開発者の間には、まさにこのような力学が働いています。開発者にとって、苦労して作り上げたソフトウェアが、開発の苦労を知らない外部の人間によって否定され、さらに修正作業という余計な仕事まで押し付けられるのですから。

私は以前からセキュリティの分野に携わっているため、双方の言い分がよくわかります。結論から言えば、ペネトレーションテスターは開発者を嫌ってなどいません。彼らもまた、過酷な業務と大きなプレッシャーの中にいるのです。そのため、本来であればコードレベルで簡単に修正できるはずのありふれたセキュリティバグが次々と見つかることで、本当に深刻な問題に対処するための時間やリソース、思考力が奪われてしまっているのです。

私は以前、ペネトレーションテスターを親のような存在だと考えていました。彼らは開発者に成功してほしいと願っており、それが叶わなかった時、怒っているのではなく、ただ失望しているだけなのです。

少し極端な例えかもしれませんが、この視点を踏まえた上で、さらに深く掘り下げてみましょう。なぜ開発者の間でこのような世界観が生まれてしまったのでしょうか？

「当然、防御的になりますよ。彼らは私に仕事のやり方を指図しているんですから！」

自分の仕事が悪いと言われたり、成果を否定されたりして気分のいい人はいません。残念なことに、開発者にとって静的解析やペネトレーションテストの結果は、まるで通知表のように感じられます。低い評価を下されたとしても、結局のところ彼らの上司が評価するのは、ソフトウェアに脆弱性があるかどうかではなく、どのような機能をいつまでに実装したかという点なのです。

ペネトレーションテスターにとっても、これは「使者に罪はない」という状況です。個人的な感情ではなく、バグを見つけるという任務を遂行しているに過ぎません。もちろん、人によっては態度が厳しいテスターもいるかもしれませんが、彼らは開発チームを追い詰めるために仕事をしているわけではありません（そうあるべきではありません）。セキュリティのベストプラクティスについて両チームが共通認識を持てれば、双方にとってずっと楽になるはずです。開発者に完璧を求めているわけではありません。現実的に見て、テストチームの存在意義は、脆弱なコードがリリースされるのを防ぐことにあるのです。

「こんな些細な問題を全部直せと言われても、もっと優先すべきことがあるって知らないのか？ それに、そんなに重要だと思うなら、なぜ修正を手伝ってくれないんだ？」

確かに、開発者にとって最優先事項は常に機能の実装であり、急速なデジタル化が進む現代では、スピードが求められます。セキュリティやセキュアコーディングに個人的な関心を持つ開発者もいますが、一般的にはセキュリティは「誰か他の人の問題」と見なされており、その「誰か」にはペネトレーションテスターも含まれています。

最も一般的な脆弱性は、実は修正が容易なものです。クロスサイトスクリプティング（XSS）やSQLインジェクションなどは、一度知ってしまえば修正は難しくありません。問題は、多くの開発者がそもそもそれらを混入させていることに気づいていない点です。こうした些細に見える問題こそが、攻撃者が企業に壊滅的な被害を与えるための小さな入り口となります。Akamaiの調査によると、2017年11月から2019年3月までの間、SQLインジェクションの脆弱性はすべてのWebベースの攻撃ベクトルの65%を占めていました。20年以上も前から修正方法が確立されている脆弱性に対して、これは非常に深刻な統計です。

ペネトレーションテストチームの中には修正を支援してくれるところもありますが、悪いニュースを報告するだけで、開発者が別のプロジェクトに移っていたとしても修正を求めるケースもあります。また、開発チームにとって修正が不可能（あるいは修正を期待すべきではない）なバグが報告書に含まれることもあります。それでも、それらは報告書の一部として扱わなければならず、やはり個人的に受け止めるべきではありません。

理想的な妥協点は、ペネトレーションテスター、セキュリティ担当者、開発マネージャーがメンターのような役割を果たし、チームが必要とする効果的なトレーニングやツールを提供することです。これにより、個々の開発者がSDLCの初期段階からセキュアなコーディングを行えるようになります。両チームが歩み寄り、健全なDevSecOpsの実践として、最初からセキュリティを考慮することが重要です。

「自分は評価されている以上にセキュリティの知識がある。このレポートの指摘はほとんどが誤検知か、重要ではないものだ。」

静的解析はSDLCにおけるセキュリティプロセスの一要素であり、静的解析ツール（SAST）は基本的な役割を果たしています。確かに、誤検知はこれらのスキャナー（DAST/IAST/RAST含む）における課題です。ただでさえ遅いプロセスをさらに煩雑にし、手動でのコードレビューを強いることで、開発者とテスター双方にプレッシャーを与えています。ペネトレーションテスターは、不正確な結果を避けるためにカスタムルールを細かく設定し、企業固有のガイダンスを提供していますが、それでも誤検知は発生し、開発者を困惑させてしまうのです。

このプロセスは完璧ではありませんが、もう一つの問題は、多くの開発者が一般的な脆弱性の多くを継続的に軽減するための十分な知識を持っていないことです。高等教育においてセキュリティ教育が不足しており、職場でのトレーニングも効果にばらつきがある現状では、過信が働いている可能性も否定できません（これは開発者の責任ではなく、業界全体として彼らに必要な知識やツールを提供できるよう改善していく必要があります）。

「このアプリケーションがテストされるとは知らなかった。それなのに、今になって修正作業に追われる羽目になった」

多忙なエンジニアの中には、ペネトレーションテスター（ペンテスター）が今か今かと待ち構えていて、アプリケーションをテストして開発チームの計画を台無しにしようとしている、と思い込んでいる人がいます。彼らは「過剰にテストしている」「あら探しをしている」「余計な仕事を作っている」と見なされがちです。

しかし、問題は彼ら自身も過酷な状況にあるということです（実際、サイバーセキュリティ人材の不足は深刻なレベルに達しており、悪化の一途をたどっています）。彼らには、理由もなくテストを行う時間などありません。テストの優先順位を決めるのは彼らだけではなく、経営層や顧客からの要請、セキュリティ監査の一環、あるいはバグバウンティプログラムの結果として決定されることもあります。

開発者にとって、現在進行中の機能開発スプリントを中断してセキュリティ修正に取り組むことは、特にそれが自分の担当したコードでない場合、非常に煩わしいものです。以前のチームや別のベンダーが更新を担当した可能性もあります。しかし、セキュリティは全員の問題です。すべてのセキュリティバグを自分が作り出したかのように責任を負う必要はありませんが、セキュリティは共通の責任であるという認識を持つことが不可欠です。

今後どうすべきか？

時には、考え方を少し変えるだけで、問題解決に向けた大きな前進につながることがあります。ペンテストの結果が思わしくないとき、開発者が冷ややかな反応を示すことについて触れましたが、それを「挑戦」と捉えてみてはどうでしょうか。ペンテスターを、自分の土俵で打ち負かすべき「良きライバル」と考えてみるのです。セキュリティ意識の高い開発者がコードを書く段階で一般的なバグを排除できれば、ペンテスターの仕事は非常に難しくなります。逆に、セキュリティを軽視する開発者は、簡単にソフトウェアを突破され、ペンテスターに完敗することになるでしょう。

ペンテスターと開発者が常に完全に調和しているとは限りませんが、組織がセキュリティを最優先事項とし、チーム、特に開発者が成功するために必要な知識とツールを提供することで、両者の関係は劇的に改善されます。結局のところ、全社的な前向きなセキュリティ文化を優先できるかどうかが鍵であり、現在苦戦を強いられている一般的な脆弱性との戦いに勝つためには、そうした文化の醸成が不可欠です。