開発チームを理解する

部門横断のプログラムを導入するには、どのような場合でも共感が必要です。セキュリティチームと開発チームは、視点や目標が大きく異なるため、連携がうまくいかなくなることがよくあります。どちらのチームも、アプリケーションを安全にするという同じ最終目標を掲げているかもしれませんが、望ましいワークフローや成功の測り方は大きく異なる場合があります。幸いなことに、共感によって連携を促進できます。

強固で自然な導入を実現するには、セキュリティチームと開発チームが同じ言葉で話し、共通の目標に向けて協力する文化を築くことが重要です。セキュリティチームの役割は、エンジニアリングチームを監査し、仕事を増やすことではありません。エンジニアができるだけ早く、迅速かつ効果的にセキュリティの問題を見つけて対処できるよう、支援することです。エンジニアリングチームは、セキュリティチームを自分たちの目標達成を支援してくれる存在と捉える必要があります。そうでない場合は、助けを求められる関係を築くべきです。

最新のAppSecプログラムを展開する際は、開発チームと連携し、その活動を支援する人たちが、開発者が現在直面している課題や摩擦、不満を明確に理解していることが欠かせません。そうした状況を理解して初めて、開発プロセスにセキュリティをどう組み込むべきかが見えてきます。新たな連携を始める前に評価し、把握しておきたい点を詳しく見ていきましょう。展開を始める前に、自分自身に問いかけてみてください。

「セキュリティはパートナーシップでなければなりません。セキュリティ上の失敗が多く起きる根本的な理由は、支援しようとしているグループと真に協力するのではなく、こちらのやり方を押し付けてしまうことです。私の役割は、Mandiantのエンジニアリングチームが、優れた、安全で機能的なコードを迅速に開発できるよう支援することです。ビジネスとして迅速に動く必要があります。パートナーシップを築くことで、ビジネスとセキュリティのニーズを満たすものを生み出せるのです。」

Tim Crothers、Mandiant シニアバイスプレジデント兼最高セキュリティ責任者

開発チームにどれほど共感し、その状況を理解できていますか？

開発チームの働き方や意思決定の方法を理解することは重要です。チーム全体のアプローチや開発の成熟度を理解すれば、期待値を現実的に設定し、実際に何をどこで変えられるのかを見極め、最適な支援や後押しの方法を判断できます。理解がなければ、開発チームの視点を把握できず、摩擦が生じて成功の可能性が低下します。また、以下のトピックを検討する際、同じ事業部や部門内でもチームごとに答えが異なる可能性があることを忘れないでください。開発チームについて決めつけず、文化やアプローチにどのような違いがあるかを考慮しましょう。

変化を受け入れる意欲はどの程度ありますか？

最新技術に強い関心を持ち、時には熱心になりすぎるほど、新しいツールやテクノロジー、ライブラリ、プログラミングモデルなどを、常に新しい状態を保つため、あるいはより良い解決策になるかもしれないと試す開発チームもあります。一方で、既存の課題がある場合や、その変更によってアプリケーションに影響する問題が解決すると確信できる場合に限り、こうした変更を行うチームもあります。また、「壊れていないものは直さない」という考えのもと、基本的に変化を避けるチームもあります。

開発チームがどの程度変化を受け入れるか、その行動や考え方を把握しておくと、共通の目標やAppSecプログラムの目指す姿を見つけるために、どのように協力すべきかを判断できます。たとえば、過去にGitのプルリクエスト（PR）でのテストを拒んだことがあるなら、PRにセキュリティテストを追加しても、以前の試みと違って受け入れられるとは限りません。

開発チームの成熟度や適応力を見積もるうえで重要なのは、技術の導入とプロセスの導入を区別することです。成熟度が低い企業や創業から間もない企業では、プロセスの標準化よりも技術の導入を優先する傾向があります。たとえば、スタートアップは市場にいち早く参入するために迅速なリリースを必要とし、プロセスや標準の成熟は優先順位が低くなります。こうした段階にある企業に、セキュリティプラクティスをゲートとして導入してもらうのは非常に困難です。

チームやプロジェクトの定義はどれほど明確ですか？

セキュリティ担当者と開発者の視点における大きな違いの一つは、資産のオーナーシップです。セキュリティチームから見ると、エンジニアリングチームが所有する資産は複数あり、その重要度もさまざまです。一方、開発者から見ると、それぞれのチームには担当領域があり、所有するプロジェクトやサービスがあります。また、他のチームが所有するプロジェクトに貢献することもあれば、多くのチームが利用し依存しているものの、特定のチームが所有していないプロジェクトに貢献することもあります。

この点を踏まえると、開発チームにコードやプロジェクトのセキュリティ責任を担ってもらえるかどうかは、それぞれのプロジェクトのオーナーシップによって異なります。担当範囲が明確であるほど、開発チームがそのプロジェクトのセキュリティ責任を引き受ける可能性は高まります。

また、チームの設立時期も展開方法に影響します。理想的には、新しいチームの立ち上げ時から標準やプロセスを導入できます。しかし、実際には自然な変化の機会を活用するほうが現実的です。たとえば、プログラムとは関係のない大きな変化（新しいマネージャーの着任、チームの再編など）がある場合、チームが自分たちの働き方を定める中で、新たな開発標準を受け入れる可能性が高くなります。

チームの現在のキャパシティはどの程度ですか？

ほとんどのチームと同様に、開発者は仕事が来るのを待っているわけではありません。増え続けるToDoリストのすべてをこなせないと分かっていても、次に取り組むべき重要なタスクに優先順位を付けています。すでに仕事であふれている開発者やチームに、さらにタスクを追加しても、建設的でも支援的でもありません。人員が不足しているチームが、次々とスプリントをこなしながら、何とか対応を続けている状況では、なおさらです。

「彼らには他にも多くの責任があると理解しています。機能や製品を開発し、パフォーマンスや信頼性にも気を配らなければなりません。セキュリティへの参加をできるだけ簡単にしたいと考えています。」

Jason Chan、Netflix セキュリティ担当バイスプレジデント

組織全体で、チームのスキルにはどの程度幅がありますか？

開発チームの状況を時間をかけて理解する必要があるのは、チームごとに違いがあるからです。新しいテクノロジーやプロセスをいち早く取り入れる先進的なチームが少数あり、組織内の他のチームが時間をかけて追随するケースはよくあります。大多数への導入は、最初はゆっくり進みますが、自動化やベストプラクティスが十分に整って他のチームの導入障壁が下がると、加速します。もちろん、広く導入してもらうには障壁を大幅に下げる必要があるということは、多くのチームが導入にかなりの時間を要する、あるいは導入しない可能性があるということです。開発者による導入を促すには、導入のハードルを下げる必要があるチームの数だけでなく、自動化やプラクティスを整えるために試験導入を担えるチームも把握しておく必要があります。

チームのスキルの幅は、インテグレーションを追加する傾向や、フィードバックを受け取る意欲にも表れます。一般に、成熟したチームはフィードバックを求め、できるだけ早い段階で受け取ろうとします。IDEやローカルビルドプロセスの自動化に加え、Gitリポジトリでもフィードバックを得たいと考えます。成熟度が低いチームは、CIプロセスでの自動化しか望まない場合があり、その場合フィードバックを得るのは遅く、通常は本番環境へのデプロイ直前になります。こうした異なるチームを同じ展開グループに加えてもうまくいく可能性は低く、成熟度の低いチームにとって負担が大きくなるでしょう。

導入状況にばらつきが生じる一般的な原因として、プロジェクトの複雑さや古さが挙げられます。積極的に開発するのではなく保守されている、古くて複雑なサービスは、プロセスを変更する際に強い抵抗が予想されるため、導入対象として適していません。同様に、組織が買収などを通じて非連続的に拡大した場合、異なるテクノロジーやパイプライン、文化を引き継ぐことになります。その結果、組織全体の一貫性が損なわれ、チームについての想定が実態と異なる可能性も高まります。

開発チームは現在、パイプラインにセキュリティプラクティスをどのように組み込んでいますか？

組織内の開発チームを時間をかけて評価したら、次に、現在どのようなセキュリティプラクティスに従っているか、どのように実践しているかを把握し、基準となる状態を定めて、そこから取り組みを進めることが重要です。開発チームは通常、最初はセキュリティにあまり介入しない方法から始めます。たとえば、状況を把握するためだけに定期的にテストを実行し、可能であればパイプラインに組み込むといった形です。最初の段階では、ブロックやゲートを設けず、開発チームが慣れ親しんだ速度でリリースを続けられるようにすることが多いでしょう。

インテグレーションに関するチームの好みも確認しましょう。たとえば、CIでスキャンやテストを行うのか、それともPRの段階で行うのか。すぐに使えるインテグレーションを利用しているのか、それともパイプラインやプロジェクトに合わせてスクリプトや自動化を実装しているのか。IDEでテストを行うのか、それとも問題が起きてから対応するのか。インテグレーションを重視するチームは、開発者向けの統合型セキュリティソリューションを導入する可能性が高いでしょう。

「私の考えでは、重要なのはエンジニアリングチームが望むプラクティスを理解することです。どのようなパターンがあるのかを把握し、コントロールではなくガードレールを設けるために、チームと協力するのです。チームが望む成果を支援したいと考えています。チームが適切だと判断したプラクティスやプロセスが確実に実践されるようにする必要があります。通常、そこは協力して進めます。簡単に言えば、常に探しているのはギャップです。プロセスのギャップ、[連携]のギャップです。」

Tim Crothers、Mandiant シニアバイスプレジデント兼最高セキュリティ責任者

スプリント中、セキュリティの優先順位はどのように決めていますか？

チームのセキュリティへの取り組み状況を知るもう一つの指標は、将来の開発とバックログのどちらに重点を置いているかです。バックログには何千もの問題や脆弱性が含まれ、圧倒されることも少なくありません。一方、新機能によって新たに生じる問題は、ほんの数件かもしれません。また、何が重要、あるいは修正が必要なのかを判断するために、チームがどのように問題をトリアージするのか、いつ、どのようにエスカレーションするのかを理解することも大切です。バックログに関するOKRがあり、着実に前進するためのプロセスが整っているチームは、目標達成を早めるツールを導入する可能性が高くなります。

セキュリティテストや修正を、スプリントにどのように組み込んでいますか？コードを納品する前にセキュリティテストをクリアする必要があるでしょうか。それとも、セキュリティ関連のタスクを技術的負債のバックログに追加し、数か月ごとに1スプリントを使って問題を修正するのでしょうか。後者は、成熟度がそれほど高くないチームや、スプリント内で作業を完了できない一部のパフォーマンスが低いチームによく見られます。こうした場合、スケーリングやパフォーマンス、信頼性のためにも専用スプリントを設けることが多く、セキュリティスプリントと時間を取り合うことになります。

最後に、チーム内でテスト方法が文書化されているか、または問題への対応に関するSLAが設定されているかを確認しましょう。こうした質問は、チームの現状を把握するだけでなく、テストをより簡単にし、適切なことに集中できるようにするための次のステップを考えるうえでも役立ちます。