DevSecOpsプログラムの成功

セキュアな開発の向上は時間をかけて取り組むもので、まずは各チームが現在行っているセキュリティプロセスや実践状況を可視化することから始まります。共感を持って進めなければ、この取り組みは開発上の不備への非難と受け取られる可能性があります。責任を追及されたり、評価されたりしていると感じると、防御的な反応を招きやすくなります。これを避けるには、チャンピオンにチームのプロセスや実践状況を自己評価するスコアカードを作成してもらうのが効果的です。これなら、私たち対彼らという構図を生むことなく、じっくり振り返る時間を確保できます。スコアカードには、さまざまなセキュリティ上の行動、テストの種類、プロセスなどに関する質問が含まれ、開発チームは各項目で現在どの程度実践できているかを回答します。チームによって注力する分野に偏りがあるのはよくあることで、まったく問題ありません。

次のステップは改善です。ここでセキュリティチームが開発チームを支援し、サポートできます。開発主導の改善の好例として、スコアカードの項目のうち改善したいものを開発チームに選んでもらう方法があります。選ぶのは2、3項目で十分です。そのうえで、改善プロセスをいつまでに導入するかを決めてもらいます。たとえば、コードレビューにセキュリティに関する質問を取り入れることや、バックログにあるCVSSスコア9.5以上の重大度の高い脆弱性をすべてなくすことなどが考えられます。目標が何であれ、開発者が主導し、責任を持つことが重要です。セキュリティコーチは、チャンピオンが目標を実現できるよう支援します。教育やアドバイス、パイプラインの変更など、必要なサポートを提供し、セキュリティチャンピオンが望む変更を展開できるようにします。

ただし、重要な前提があります。セキュリティコーチの成功（正式なKPIとなる場合もあります）は、セキュリティチャンピオンの成功にかかっています。セキュリティチャンピオンが目標を達成するか、進捗計画を前進させて初めて、セキュリティコーチも成功したと言えます。この共同の成功指標は、両チームが協力して実現を目指す、セキュアな開発という共通目標を支えるものです。

セキュリティチャンピオンプログラムでよく行われるもう一つの活動が、脆弱性管理です。脆弱性がどこにあるかを可視化することは、アプリケーションやデプロイの問題が集中している箇所を明らかにするうえで有効です。しかし、大規模なプロジェクトやデプロイでは、開発者がプロジェクトのバックログで対処する脆弱性の数が膨大になり、すぐに手に負えなくなることがあります。脆弱性のトリアージ、対応不要とする判断、優先順位付けや、バックログにある脆弱性および新たに特定された脆弱性への対応は、開発部門とセキュリティ部門の双方で行えます。アプリケーションのフロー、アーキテクチャ、設計については、開発チームのほうがセキュリティチームよりも深く理解しています。一方、脅威やリスクについては、セキュリティチームのほうが開発チームよりもよく理解しています。チャンピオンとコーチの関係に限らず、オープンなコミュニケーションを保って協力することで、こうした議論や評価をより簡単かつ迅速に進められます。

セキュリティチャンピオンプログラムの始め方と展開方法

まず、明確さとシンプルさが非常に重要であることを忘れないでください。プログラムを始める際には、セキュリティチャンピオンプログラムの内容や目標を人々が読んで理解できるだけの情報を用意し、ビジネスにおけるスポンサーシップと重要性を示しましょう。開発者を念頭に置いて作成し、文書を書くときには開発者から意見をもらいましょう。

プログラムの初期規模を検討する際に最も重要なのは、展開の規模を大きくしすぎたり、急ぎすぎたりしないことです。自社や各チームに固有のベストプラクティスを見極め、学び、以降の展開に活用しましょう。初期展開の対象チームを選ぶ際には、次のようなチームを検討してください。

• ビジネスにおいて最も重要なサービス、アプリケーション、チームのうち、リスクが最も高いもの

• セキュリティと開発の実践が最も成熟しており、変化に適応できるチーム

• セキュリティチームとすでに関係を築いているメンバーがいるチーム

• セキュリティへの関心が高く、チームのセキュリティ態勢や衛生状態の改善に前向きなメンバーがいるチーム。

まず少数のチームから始めれば、必要に応じて各チームに十分な時間をかけられるため、展開が失敗するリスクを減らせます。チームのニーズを特定する際には、この早い段階で把握できるのであれば、複数のチームに共通する課題も検討しましょう。たとえば、3つのチームにプログラムを展開し、すべてのチームが脅威モデリングの導入を希望するなら、チーム間で知見を共有し、取り組む要素を絞ることができます。

適切なセキュリティコーチを選ぶことも同じくらい重要です。コーチは開発チームの主な連絡窓口となります。優れたコミュニケーション能力があり、（できれば）エンジニアリング経験を持ち、開発者に寄り添える人を選ぶことが大きな違いを生みます。

初期段階では、意欲を高め、さらに成長しようという関心を育むために、惜しみなく報酬や評価を与えましょう。今後ほかのチームでも活用できるよう、ベストプラクティスガイドの作成も始めてください。また、次のチームが最新かつ有用な情報を得られるよう、既存のドキュメントやガイドも必要に応じて更新しましょう。

プログラムを社内全体に広げる際は、ビジネスのあらゆる領域をより適切にカバーできるよう、組織内の異なる部門に属するほかのグループを選ぶことも検討しましょう。ロードショーを実施して、提供できていない支援についての情報を集めるとともに、すでに参加しているチームの成功事例を共有するのもよいでしょう。また、プログラム内で成功事例を共有し、チーム同士の取り組みを見えるようにすると、互いに競い合う雰囲気が生まれ、チーム同士が高め合えることもよくあります。

プログラムを開発チームに展開するときは、チームの行動や新たな学び、責任ある取り組みを評価し、さらに多くの責任を任せましょう。奇妙に聞こえるかもしれませんが、最終的には開発チームの自律性を高めることが目標です。セキュリティを担う能力と意欲を示したチームには、より大きな権限と裁量を与えましょう。

開発者にプログラムを浸透させる

開発組織の課題やニーズを理解することは、プログラムを開発者に浸透させるうえで重要です。ボランティアのみでプログラムを拡大するのか、マネジメントがメンバーを選ぶのか、あるいはその両方を組み合わせるのかにかかわらず、参加者が積極的に関わり、貢献できるようにする必要があります。

プログラムを実施する理由を明確に示すことが重要です。プログラムの目標に加えて、開発部門とセキュリティ部門のメンバーそれぞれの役割と責任を明確にすれば、誰もが安心してプログラムに参加し、意欲的に関われるようになります。プログラムの重要な特長の一つは、開発部門とセキュリティ部門がチームとして連携し、セキュアなコードとアプリケーションの開発・提供という共通の目標に取り組むことです。特に開発者の賛同と、セキュアな開発への意欲を得るには、セキュリティ業務を基本的に開発業務の一部として捉えることが重要です。

教育のトピックを選ぶとき、開発者にタスクを依頼するとき、チケットなどを管理するときには、開発者を対象とすることを常に意識することが重要です。開発者は、すでに知っている基礎情報を学ぶより、ベストプラクティスに関心を持つことがよくあります。コンテンツを実践的かつ技術的で、問題解決に役立つものにすることが、その効果を高める鍵です。

コミュニケーションややり取りを行う場所など、細かな点も重要です。たとえば、開発チームに対応してもらうチケットを起票する場合は、チームが使い慣れたチケット管理システムを使いましょう。すでにJiraを使っているなら、Jiraでチケットを作成します。開発チームに利用を求めるツールやサービスが増えるたびに、参加への障壁が一つ増えると考えてください。

前述のとおり、セキュリティチャンピオンに期待される個々の責任や役割を明確にすることも同じくらい重要です。公式な役割を設け、チームのセキュリティ関連活動に充てる時間を明示すれば、より明確になります。いずれの場合も、今後3～6か月間にチャンピオンに取り組んでもらう目標や活動を2、3個示せば十分です。チャンピオンに過度な負担をかけず、最も重要な活動に集中してもらえます。

先ほど、報酬や評価の重要性に触れ、こうした活動がビジネスにもたらす価値を示す方法をいくつか紹介しました。成功を称えることは、必ずしも誰かをカンファレンスに参加させることではありません。多くの場合、誰かの努力を称えてさらなる取り組みを促し、その人の支援者や擁護者となることが大切です。同時に、こうした行動は、ほかの人も同じ評価を得ようと一歩踏み出すきっかけになります。

成功とはどのような状態か

まず、数週間、あるいは数か月で素晴らしい成果が出ると期待してはいけません。このようなプログラムを立ち上げるのは、開発プロセスや実践を改善し、ソフトウェアをセキュアに提供できるようにするためです。一夜にして解決できるものではなく、人が関わる変化にはさらに時間がかかります。恣意的な目標に合わせるのではなく、適切な判断を行えるよう、現実的な変化と成功のタイムラインを設定しましょう。

導入状況

セキュリティチャンピオンプログラムで重要な指標の一つは、どれだけ導入が進んでいるかです。前述のとおり、各チャンピオンが自発的に参加することが重要です。そのため、チャンピオンの総数、グループの継続的な成長、チャンピオンの定着率が、導入の成功を示す指標になります。

もう一つの有用な指標は、チャンピオンプログラムを通じてセキュリティ部門が支援した開発チームの数と、それが開発組織全体に占める割合です。急速に規模を拡大すると失敗しやすいことを忘れずに、目標は無理に押し付けるのではなく、達成可能で自然なものにしましょう。

エンゲージメント

次に追跡すべき指標はメンバーのエンゲージメントです。これは、プログラムと人間関係がうまく機能しているかを示します。チャンピオンがセキュリティ活動に実際に週の10～20%を費やしているかを追跡するのは難しく、そもそも追跡する必要はないでしょう。重要なのは、エンジニアのセキュリティ業務を本人の時間に行う追加作業にするのではなく、業務の一部として公式に支援することです。また、この時間はあくまで概算であり、需要に応じて週ごとに変動します。

より適切な指標は、定例会議への参加からチーム内で主導する取り組みまで、チャンピオンが何に関わっているかです。前者は、毎月の電話会議に定期的に参加するチャンピオンの数や、セキュリティコーチとの週次の連絡に参加するチャンピオンの数を記録すれば簡単に追跡できます。このデータをチャンピオンに不利益な形で使うのではなく、プログラムで扱うコンテンツや活動を改善し、チャンピオンにとっての魅力と関連性を高めるために活用しましょう。

インパクト

前述のとおり、開発組織がチーム内の変更や改善を主体的に進められるようにすることが重要です。どこまで任せるかは状況次第ですが、チームが何に取り組み、何を改善し、何を完了したかを把握することは、プログラムがもたらした効果を測る確かな指標となります。

スコアカードの手法を使ってこれを実現するには、開発チームに自分たちのプラクティスやプロセスを自己評価してもらうのが効果的です。まず、チームのスコアカードを作成している人は何人いるでしょうか。最大のリスクや、最も迅速に実施できる修正などを把握できるよう支援したうえで、セキュリティチームのサポートを受けながら、チームが主体となって改善計画を作成し、主導しているでしょうか。そしてもちろん、各チームの計画に対する進捗も測定しましょう。この改善の進捗を測る指標は、推進担当者とコーチの双方が責任を持つKPIにするべきです。

進捗

すでに述べたように、推進担当者が求める教育と、セキュリティにあまり関心のない開発者が求める教育には違いがあります。それ自体は問題ありませんが、学習の進捗を測定し、追跡することも大切です。社内外の認定資格や、セキュリティ業務に取り組んだ時間など、どのような教育方法を採用するかを決めたら、ベルトやメダル、認定資格を使ったモデルでチーム全体のスキルレベルを可視化し、四半期ごとの改善目標を設定しましょう。

ダッシュボード

最後に測定する領域は、影響を受ける指標とも考えられる、プロダクトセキュリティのダッシュボードです。ここには、脆弱性の統計、テスト数、チームへの導入状況などが表示されます。背景情報がなければ、こうした数値はプロジェクトの品質やリスクを正確に反映しないことがあります。たとえば、あるチームが別のチームより多くテストを実施している場合、問題の可視性と把握度が高いために、より多くの脆弱性が見つかる可能性があります。検出数が多くても、そのチームのリスクが高いとは限りません。

背景や理由を添えてチームごとの影響を示せることには、大きな価値があります。こうした指標を測る際は、それらに影響するプロセスやプラクティスも必ず測定しましょう。たとえば、チームが実装するすべての機能について脅威モデリングを行えば、そのプロジェクトのリスクを大幅に低減できます。開発時に発見される脆弱性の数にも影響するため、こうした背景情報を加えることで、結果をより深く理解できます。