私のペンテスト、私の敵？開発者が語る、ペンテストと静的解析の結果についての本音

本来の開発者は、厳しい納期の中で素晴らしい機能をコーディングするために、深い集中力を発揮するものです。機能構築は、私たちが最も好きな仕事であり、ソフトウェア開発ライフサイクル（SDLC）の基本的な成果でもあります。

しかし、以前にもお話したように、私たちの多くは、セキュリティのベストプラクティスよりも機能を優先しているのが現状です。結局のところ、ほとんどの組織では、それが誰かの仕事であるように設定されており、私たちに対する十分なセキュリティトレーニングは限られています。侵入テストや静的解析スキャンツール（SASTとして知られています）は、セキュリティリスクを軽減するための全体的なプロセスの一部に過ぎず、私たちの仕事とは無関係に動作しています...もちろん、コードがホットフィックスのために私たちに戻ってくるまでは。

そしてその時、多くの開発者は「ペンタゴンに嫌われているのではないか 」と考えるのです。

このような相互作用がチームや文化を決定づけることがよくあります。気になるのは、コミュニケーションや理解、全体的なコラボレーションが不足しているために、少なくとも開発者側に緊張感が生まれていることです。考えてみてください。あなたが数百時間かけて素晴らしい像を彫った後、誰かがハンマーを持ってやってきて、その像の基礎部分に問題があると言われて、像の一部を壊し始めたとします。これが、テスターと開発者の間で認識されているダイナミックな関係です。後者は、自分たちのソフトウェアの最愛の人を、プロセスを一緒に苦労したわけでもない外部の人間に虐殺され、代わりに作業量を増やし、コードを出荷する満足感を遅らせているのです。

ずいぶん前にセキュリティ分野に進出した私には、どちらの言い分も理解できます。そして、ペンテスターは開発者を嫌ってはいません。ペンテスターは、おそらく過労と大きなプレッシャーにさらされています。そのため、コードレベルで簡単に修正できる一般的なセキュリティバグが次々と発生し、本当に深刻な問題から時間、リソース、頭を奪ってしまうのです。

私はいつもペンタリストを親のようなものだと思っています。彼らはあなたにうまくやってほしいと思っていて、そうでないときは...彼らは怒らないし、ただがっかりするだけです。

さて、このような（ちょっと不謹慎かもしれませんが）イメージを皆さんにお持ちいただいたところで、もう少し掘り下げてみましょう。開発者がこのような世界観を持つようになった原因は何でしょうか？

"当然、私は身構えています。彼らは私の仕事のやり方を教えてくれているのですから！"

自分が悪い仕事をしたと感じたり、誰かに自分の仕事を気に入られていないと感じたりすることは、誰もが好まないことです。開発者にとって悲しいことに、静的解析やペンテストの結果が返ってくると、それが成績表のように感じられることがあります。彼らは低い評価を受けていますが、最終的に上司が彼らを評価するのは、ソフトウェアに脆弱な要素があったかどうかではなく、彼らが構築した機能と、それらを提供した時間です。

かわいそうなペンタリストにとって、これは「メッセンジャーを撃つな」というケースです。彼らはバグを見つけることを使命としており、バグを見つけたのです。確かに、個人レベルでは、他の人よりも不機嫌なペンテスターもいるかもしれませんが、彼らは開発チームをはりつけにしようとしているわけではありませんし、そうすべきでもありません。セキュリティのベスト・プラクティスを構成するものについて、両チームが同じ見解を持っていれば、両者にとってはるかに容易なことです。現実的には、テストチームは開発者が脆弱なコードを出荷しないように保護するために存在するのです。

"些細な問題をすべて解決するように言われたが、もっと優先順位の高い問題があることを知らないのか？そして、そんなに気になるなら、なぜ直すのを手伝ってくれないのだろう？"

開発者の最優先事項は常に機能の構築であり、デジタル化が急速に進むこのクレイジーな世界では、それをスピード感を持って行わなければならないのは事実です。コーダーの中には、セキュリティや安全なコーディングに個人的な興味を持っている人もいますが、一般的には、セキュリティは「他人の問題」であり、そこには必然的にペンテスターも含まれます。

クロスサイトスクリプティング（XSS）やSQLインジェクションなど、一般的な脆弱性のほとんどは、修正するにしても実に小さな問題です。問題は、多くの開発者がそもそも脆弱性を導入していることに気付いていないことであり、このような一見小さな問題は、攻撃者が企業に壊滅的な問題を引き起こすために必要な、わずかな機会の窓なのです。アカマイによると、2017年11月から2019年3月の間に、SQLインジェクションの脆弱性はウェブベースの攻撃ベクトル全体の65％を占めています。20年以上前から修正プログラムが知られている脆弱性としては、気が遠くなるような統計結果です。

一部のペンテスト・チームは、セキュリティ・バグの修正を支援しますが、他のペンテスト・チームは、たとえその時点で開発者が別のプロジェクトに移っていたとしても、悪いニュースのレポートを提供し、ホットフィックスの作業を期待します。また、場合によっては、開発チームが修正できない（あるいは修正を期待すべきでない）バグを含むレポートに直面することもあります。

このための「ハッピー・ミディアム」は、ペンテスター、セキュリティ担当者、および開発マネージャがより指導的な役割を果たし、チームが効果的なトレーニングやツールの面で必要なものを持っていることを確認し、個々のコーダーがSDLCの最初から成功して安全にコーディングするための最良のチャンスを与えることです。健全なDevSecOpsの実践の一環として、セキュリティが最初から考慮されていることを確認するために、両チームは本当に半分ずつ会うべきです。

"私は自分が評価されているよりもはるかに優れたセキュリティ知識を持っています。これらのレポートはほとんどが誤検出であり、重要ではありません。

静的解析は、SDLCにおけるセキュリティプロセスの要素であり、静的解析スキャンツール（SAST）は基本的な役割を担っています。そして、これらのスキャナや他のタイプ（DAST/IAST/RAST）のスキャナでは、誤検出が問題となります。これは、ただでさえ時間のかかるプロセスにおける厄介な問題であり、手動でのコードレビューを必要とし、開発者とペンテストの双方にプレッシャーを与えます。ペンテスト担当者は、時間をかけて不正確な読み取りを避けるためのカスタムルールを綿密に設定し、企業特有のガイダンスを提供してきましたが、一部の誤った読み取りが紛れ込み、開発者の目の前で頭を悩ませることになるのです。

このプロセスは完璧ではありませんが、もう一つの問題は、多くの開発者が、多くの一般的な脆弱性を一貫して緩和するための十分な知識を持っていないことです。高等教育ではセキュリティに関するトレーニングはほとんど行われておらず、実地研修の効果にもばらつきがあるため、自信過剰になるのも無理はありません（これは開発者のせいではなく、業界として開発者に必要な知識をもっと提供する必要があります）。

"このアプリケーションがテストされることを知らなかったが、今では修復作業に追われている"

時には、ペンテスターは、アプリケーションをテストして、開発チームのパレードに雨を降らせる瞬間を待っているだけだと、過労のエンジニアが思い込んでいることがあります。彼らは過剰なテストを行い、細かくチェックし、余計な仕事を増やしているのです。

唯一の問題は、彼らもまた過労であり（実際にはそれ以上で、サイバーセキュリティのスキル不足は深刻なレベルにあり、さらに悪化しています）、理由もなくテストをする時間はありません。テストの優先順位を決めるのは、彼らだけではありません。テストは、上級管理職や顧客、セキュリティ監査の一環として要求されることもあれば、バグ報奨金プログラムの結果として決定されることもあります。

開発者にとって、現在の機能構築スプリントからセキュリティ修正の作業に引き抜かれることは迷惑なことです。特に、それが自分の作業でない場合はなおさらです。特に、自分が担当していない場合はなおさらです。おそらく、前回のアップデートは前任のチームが行ったのか、それとも別のベンダーが行ったのか。しかし、セキュリティは全員の問題です。だからといって、すべての開発者がセキュリティバグを自分で作ったかのように責任を負わなければならないわけではありませんが、セキュリティは共有の責任であるという観点から、パーティに参加する必要があります。

ここから先は？

問題解決に向けて大きく前進するためには、考え方を変える必要がある場合があります。これまで、ペンテストの結果があまり良くない場合に開発者が抱く冷ややかな反応についてお話してきましたが、もしそれを挑戦に変えることができたらどうでしょうか。おそらく、開発者は、ペンテスト担当者を友好的な競争相手、つまり、自分のゲームで勝てる相手と考えることができるでしょう。結局のところ、コードを書くときに一般的なバグを取り除くことができるセキュリティ意識の高い開発者は、彼らの仕事をはるかに困難なものにしてしまうのです。対照的に、セキュリティを意識していない開発者は、自分のソフトウェアを簡単に壊すことができるペンタリストに総合的に負けてしまうのです。

しかし、組織がセキュリティを重要な優先事項として扱い、チームに正しい知識とツールを与えて成功させることができれば、両者の関係は大幅に改善されます（特に開発者）。結局のところ、全社的に積極的なセキュリティ文化が優先されるかどうかということになりますが、一般的な脆弱性に対する（現在の）負け戦に立ち向かうためには、絶対にそうすべきです。