セキュリティチームとアプリ開発チームの緊張関係をうまく乗り越える6つの鍵

サイバーセキュリティチームと開発者の間には、常に自然な緊張関係が生じます。結局のところ、開発者の役割は「開発すること」です。組織の前進に役立つ新しいアプリケーションや機能を作り、リリースすることを望み、そのために報酬を得ています。一方、セキュリティチームの役割は、新しいソフトウェアの導入によって、データ侵害や脆弱なソフトウェアによるビジネスサービスの可用性喪失など、悪い事態が起きないようにすることです。

こうした役割の違いが両者の間に自然な緊張を生むのは確かですが、私の経験では、必ずしもそうなる必要はありません。両グループの相互理解を深めるための適切な取り組みを行えばよいのです。

残念ながら、多くの組織では適切な取り組みが行われていません。その結果、開発チームはセキュリティチームを乗り越えるべき「障害」と見なすようになります。同様に、開発者は「セキュリティを十分に重視していない」とセキュリティチームが考えることで、開発チームへの反感が強まっていきます。

開発者とセキュリティチームの関係を改善する方法については、多くのことが書かれてきました。また、過去10年間で、この緊張を和らげることを目的としたDevOpsの実践が急速に広がりました。一定の成果はありましたが、私の見解では十分ではありません。そこで、大手通信会社でアプリケーションセキュリティチームを管理し、開発者とセキュリティの緊張関係をうまく調整してきた経験から学んだことを共有したいと思います。

組織ごとに状況は異なります。開発チームやセキュリティチームが主に社内で働く場合もあれば、大部分がリモート勤務の場合、あるいは両方が混在する場合もあります。アプリケーションセキュリティの経験が豊富なチームもあれば、そうでないチームもあります。私が所属していたチームは、主に出社して働いていました。私たちに効果があった方法が、すべての組織に当てはまるとは限りません。それでも、これらの鍵を取り入れれば、セキュリティチームと開発チームの重要な関係を改善できると考えています。

鍵その1：トレーニングを重視する。

組織は、新しい開発者にアプリケーションセキュリティのトレーニングを提供すべきです。AppSecチームが主導し、開発経験が十分にあり、開発者から信頼される人が担当するのが理想です。開発経験のあるAppSecの専門家は、セキュリティチームの伝え方が適切でないときに開発者が直面する問題やストレスを理解しています。

この考え方はAppSecチームにも広く当てはまります。開発に携わったことがないセキュリティ担当者だけでAppSecチームを構成すると、両グループの間に摩擦が生じやすくなります。おそらく、いつまでも異なる「言語」で話し、互いが直面する問題や課題を理解できないからです。以前に開発者として働いた経験のある人がAppSecチームに加わると、チーム間の関係は大きく変わるでしょう。

鍵その2：AppSecトレーニングでは、開発チームとセキュリティチームが社内で実際に発見した事例を使う。

AppSecトレーニングでは、講師がインジェクションの脆弱性、クロスサイトスクリプティング（XSS）、不適切なアクセス制御など、コードに脆弱性が入り込む仕組みを解説します。また、こうした脆弱性がアプリケーションやデータのセキュリティに及ぼす影響についても説明します。内容は正確かもしれませんが、非常に味気ないものでもあります。

内容に変化をつけて関心を引くため、私たちはセキュリティチームが社内のセキュリティチェックで発見したアプリケーションの脆弱性を加え、成果を上げました。これはAppSecトレーニングを個人攻撃の場にするためではありません。個々の開発者を名指しで非難することは、絶対に避けるべきです。

大切なのは、こうした問題を一緒に学ぶことです。開発者は、構築中のアプリケーションのビジネスロジックや動作に集中しており、セキュリティには意識が向いていないことを示すのです。セキュリティの優先度が低くなることもありますが、それは理解できることです。しかし、社内で見つかった、組織のセキュリティに影響する一般的な脆弱性の例をいくつか取り上げれば、関心を引きつけられます。

鍵その3：脆弱性の発見を恥ずかしいことだと思わせない。

私たちはプレゼンテーションの冒頭で、コードにセキュリティ上の脆弱性があることへの抵抗感を和らげるスライドを紹介しました。発表者の名前は明かしませんが、そのスライドで取り上げたのは、よく知られたセキュリティの専門家です。その人物はオープンソースとして公開されているセキュリティソフトウェアを開発しています。そして、自身が作成しオープンソースで公開したソフトウェアに、非常に深刻な脆弱性が見つかったのです。

この人物でさえ深刻な脆弱性を含むソフトウェアを公開してしまうのなら、どんな開発者でも同じ間違いをする可能性があります。このスライドを紹介したのは、アプリケーションセキュリティの経験が豊富な人であっても、コードにセキュリティ上の欠陥が生じるのは普通のことだと伝えるためです。大切なのは、脆弱性を見つけて取り除くことです。

鍵その4：脆弱性が実際に及ぼす影響を教える。

私たちは社内で見つけた脆弱性を紹介するだけでなく、実際に悪用もしました。脆弱性がどのように悪用されるのか、攻撃者がそれを使って何をできるのかを開発者に示すべきです。

初期のトレーニングのひとつで、ある開発者がXSSについて、これほど有害な脆弱性ではないはずだと発言しました。そこで、XSS攻撃によって攻撃者が被害者になりすます、機密データにアクセスする、セッションを乗っ取る、キーロガーを仕込む、マルウェアを拡散するといったことができると説明しました。

これは大きな気づきにつながりました。実際、AppSecにはこのような課題があると思います。脆弱性の影響を理解していない開発者は、アプリケーションから脆弱性を修正したり、発生を防いだりする意欲を持てません。影響がわからないリスクを無視するのは、人間の自然な行動です。だからこそ、実際のリスクを示すことには大きな効果があります。トレーニングにこれを取り入れたことで、開発者との関係を大幅に改善できました。

鍵その5：セキュリティチームは、何が現実的かを理解する必要がある。

私の経験では、両チーム間の摩擦は、セキュリティチームが現実的でない作業を求めることで起こることがよくあります。トレーニングでは、開発チームにセキュリティチームとうまく連携する方法を教えることが欠かせません。しかし同じくらい、セキュリティチームが妥当な依頼をすることも重要です。

セキュリティチームが、実際には修正すべき問題ではないものを対応するよう求めると、無理な依頼になることがあります。たとえば、アプリケーションの脆弱性スキャナーを実行した結果、実在しない脆弱性や、実際のリスクを示すものではない検出結果が報告される場合です。セキュリティチームがその結果を確認せずに開発者へ渡し、修正を求めることがあります。これを何度も繰り返すと、開発者は不満を募らせ、依頼に耳を貸さなくなります。

また、脆弱性への対応に十分な時間を確保し、複雑な脆弱性の修正にはさらに時間をかけるなど、セキュリティチームは期待値を現実的に設定する必要があります。

鍵その6：精度が高く、開発者の力を引き出すツールを使う。

精度の高い評価ツールを選ぶことは重要です。そうしたツールは、特定した問題を明確に説明し、適切な深刻度を設定し、脆弱性の解決方法を案内します。これにより、開発者は目の前の問題への対処方法を理解できます。開発者が使うことを前提に設計されたツールなら、開発者が自律的に作業できるため、さらに効果的です。

セキュリティチームと開発チームの間には、ある程度の緊張関係が常に存在し、組織はそれを和らげるために継続的な取り組みを続ける必要があります。それでも、両チームの理解と共感を深めるための簡単な取り組みをいくつか行うだけで、関係を大きく改善できることがわかりました。

Snyk AI Trust Platformで開発者とセキュリティチームの連携を強化し、より良い成果を実現

ここまで紹介した6つの鍵は、開発チームとセキュリティチームの隔たりを埋めるための基本原則です。単なる理論ではなく、共感を育み、共通理解を築き、相互の尊重を深めるための実践的な取り組みです。しかし、原則だけでは不十分です。こうした働き方を実現するツールが必要です。

開発者のために作られたツールを使えば、迅速な開発と安全な開発の間にある従来の隔たりはなくなります。セキュリティは開発を止める門番ではなく、イノベーションを支える信頼できるパートナーになります。Snyk AI Trust Platformは両チームの共通基盤となり、同じ言葉で話し、同じ目標に向かって取り組めるようにします。その目標とは、安全で高品質なソフトウェアをより速く提供することです。

Snyk AI Trust Platformは、SDLCにセキュリティをシームレスに組み込み、摩擦の根本原因に直接対処できるよう設計されています。開発者が作業するIDE、リポジトリ、CI/CDパイプラインで、迅速かつ正確で、すぐに活用できるセキュリティインテリジェンスを提供し、開発者を支援します。

開発チームとセキュリティチームの真のパートナーシップを築きませんか？ライブデモを予約して、最初からセキュリティを組み込んだ開発をチームで実現する方法をご覧ください。