開発者に力を与える

開発者の自律とは、さまざまな情報をもとに自ら判断し、自分でセキュリティの問題を解決し、最終的にはアプリケーションのセキュリティに責任を持ち、主体的に取り組めるかどうかを指します。自律には支援が必要です。それは、ほかのチームから与えられ、育まれ、支えられるものです。まずは、開発者が安全なコードを提供するために必要な時間を確保できるよう、経営層からの支援について考えてみましょう。

「Netflixのカルチャーメモをウェブサイトで読むと、多くの人の目に留まるのが、自由と責任についての議論です。この考え方が、同社のエンジニアリング組織の働き方を形作ってきました。興味深いのは、人間は自由の側面に注目しがちなことです。『すばらしい。何でも好きなようにできる。責任も何か負うことになるだろうけど、それはあとで考えよう』と言うわけです。実際には、Netflixのような企業のソフトウェアを開発するには、大きな責任が伴います。サービスを停止させたくないので、信頼性は非常に重要です。ハッキングされたくないので、セキュリティも非常に重要です。つまり、エンジニアには大きな責任が求められます。私たちセキュリティ組織は、事業を支援し、可能性を広げるために存在すると考えていました。ソフトウェアエンジニアが、本来採用された領域に集中できるようにすることが私たちの目標でした。ただし、セキュリティが業務にとって極めて重要な局面に達したら、私たちに助けを求めてもらいます。その境界をどこに置くかは判断が必要ですが、セキュリティチームとエンジニアの関係が良好なら、答えを見つけられます。」

ブライアン・ペイン、BetterUp CISO、Netflix元エンジニアリングディレクター（製品・アプリケーションセキュリティ担当）

開発者がセキュリティに時間を割く動機とは？

開発者がセキュリティに時間を割きたいかどうかにかかわらず、そのための時間を確保する必要があります。また、その時間は、機能要件や非機能要件に基づくほかの成果物と並行して、セキュリティを優先できる形で与えられなければなりません。事業のニーズに応じて、安全な開発の実践にどれだけ時間をかけるか、信頼性やスケーリングへの対応とどうバランスを取るかを、開発者が判断できるようにすべきです。そうした判断をした開発者は、年度末の評価で実施したことや成果を説明し、マネージャーから支援を受けられる必要があります。開発者が時間を適切に使ったと実感できるよう、その判断を評価するのはマネージャーの役割です。そうでなければ、事業は安全な開発に時間を使うよう開発者を後押しできていません。

チームと事業のセキュリティを誰が優先すべきでしょうか？

最終的には、CEOという組織の最上層から始まります。セキュリティが事業上の課題なら、CEOが取り組むべき課題でもあります。その方針は、組織内でCIOやCTO、エンジニアリング担当のSVP／VP、ディレクター、マネージャー、チームリードへと浸透し、最終的にはテストを実行して問題を修正する開発者にまで届く必要があります。経営層の後ろ盾があれば、チームは常に新機能に追われるのではなく、セキュリティを含むエンジニアリングの健全性向上にスプリントの一定割合を充てられます。

こうした支援や優先順位付けが経営層から得られなければ、セキュリティテストが次の機能や顧客の要望と同じくらい、あるいはそれ以上に重要だと主張するのは非常に困難です。こうした取り組みが、正当性を説明しなければならない追加作業と見なされると、「何もしない」が既定の選択肢になり、議論は「どうするか」ではなく「なぜやるのか」から始まってしまいます。

これは、CEOと開発者が同じ目先の理由で取り組むという意味ではありません。開発者は自分のコードに誇りを持っています。正確で、高速で、信頼性が高く、安全なコードにしたいと考えます。一方、CEOが気にかけるのはブランドと収益であり、セキュリティインシデントやデータ侵害が事業にどれほど大きな損害を与えるかを懸念します。どちらもセキュリティを確保する正当な理由ですが、開発者の業務を増やすだけに頼るより、経営層主導でセキュリティ導入を進めるほうが大きな効果をもたらします。

「経営層の賛同について言えば、私たちの場合はCISOがCTOと密に連携していたことが大きかったです。その結果、テクノロジー部門でトップダウンの取り組みとなりました。最上層から、セキュリティの必要性が理解されていました。実際の導入は、ソフトウェアエンジニアリング組織とそのリーダーにかかっています。」

ニコラス・ヴィンソン、Pearson DevSecOpsリード

セキュリティチームは開発者を支援していますか？

アプリケーションとコードを保護する責任は開発チームにありますが、それを適切に行うにはセキュリティチームの支援が必要です。協力して取り組むことで、セキュリティチームの役割は、テストを実行して結果を提示する監査役（開発の妨げと見なされがち）から、開発者がプロセスにセキュリティを自動的に組み込めるよう支援するセキュリティエンジニアリングチームへと変わります。高リスク領域の優先順位付けについて、専門的な助言や相談にも応じます。

セキュリティチームが、ほかのタスクよりセキュリティ作業を優先するよう開発者に強制することはできません。前述のとおり、それを決めるのはエンジニアリングチーム全体と事業の優先事項です。従来、セキュリティチームは開発ライフサイクルの後半にセキュリティ監査を持ち込むため、開発者から妨げと見なされてきました。開発者が自らコードをテストし、自分自身の監査役になれるようにすれば、セキュリティチームは一歩引くことができます。そして、専門知識が必要な結果について開発チームを支援し、妨げる存在から後押しする存在へと変われます。さらにこの方法なら、開発チームのセキュリティチャンピオンを見つける余地が生まれ、協力の機会もいっそう広がります。

セキュリティチームは、脆弱性の種類や悪用された場合のリスクについて開発チームを教育することもできます。セキュリティチャンピオンプログラムを正式に実施すれば、プロセスの展開など、ほかの活動も適切に調整できます。開発チームがより自律的に取り組む一方で、事業がリスクやエクスポージャーを把握できるよう、全体的なガバナンス体制と可視性は引き続き必要です。セキュリティチームは、セキュリティテストに関するポリシーに基づいたガードレールを設け、パイプラインや開発手法に適用できます。これにより開発チームは、問題を早期に特定し、SLAを遵守しやすくなります。

「セキュリティチャンピオンと成功モデルについて考えると、エンジニアリングチームの中から、セキュリティを担う複数のメンバーを特定します。彼らが責任を持つスコアカードを作り、製品や機能を適切に保護するために行っていることを可視化します。必要に応じてエンジニアが中央のセキュリティ組織に相談できる体制を整え、最新のトレーニングも提供します。セキュリティチームがツールなどを開発する場合、セキュリティチャンピオンがその導入を推進します。セキュリティチャンピオンは、エンジニアリング組織の中にいる必要があります。外部にいてはいけません。彼らこそがセキュリティを推進するのです。」

リンキ・セティ、Bill.com VP兼CISO

開発者による導入を促すうえで、ドキュメントも非常に重要です。多くの場合、開発者が自ら執筆し、使用方法のアドバイス、判断の背景、細かな注意点など、現場の視点を提供します。セキュリティチームは、同様の実践やプロセス、ツールを導入するほかのチームとドキュメントを共有できるよう調整し、作成にも関与できます。開発者が使い慣れている優れた開発者向けツールと同様に、開発チームが自分で情報を得られる使いやすい環境を整えることが、導入の成功には欠かせません。

開発ワークフローのセキュリティルールやプロセスに関する判断は、どのように行われますか？

自律性を測る指標の一つは、開発者やチームが自分たちのプロセスやパイプラインのテストにどれだけ意見を反映し、方向性を決められるかです。セキュリティルールやポリシーを策定する際、セキュリティチームの意見を取り入れて進めるのは当然です。その後、開発チームに展開し、既存のプロセスに組み込む方法について助言を受けながら、効果的な教育を実施します。ここで重要なのは、展開と導入の方法です。開発チームが主体性を持ち、自分たちの望む形でワークフローを判断し、変更できる必要があります。各チームが独自の方法を取るべきという意味ではありません。チーム同士がベストプラクティスを学び合うことは不可欠です。開発チームには、他の開発チームやセキュリティグループの意見を踏まえて判断できる余地が必要です。それによって、導入するソリューションがセキュリティチームの求めるニーズや基準を満たせます。

このアプローチの利点の一つは、良い相互関係を生み出すことです。まず、開発チームに実践やプロセスを押し付けるのではなく、セキュリティ担当者が開発チームと協力してセキュリティ上の課題や要件を解決できます。外部から何かを押し付けられたときに自然と起こる反発を避けられます。セキュリティチームが助言する立場を取ることで、開発チームが適切な判断を下すための支援となり、受け入れられやすくなります。

最終的には、誰が主体となるかという問題に行き着きます。開発チームが書くコードのセキュリティをセキュリティチームが担おうとすると、組織全体に広くサービスを提供しなければならず、ボトルネックになる可能性があります。従来、セキュリティチームは開発組織に要件を課す役割を担いがちで、開発者からは、権限もないのに要求を押し付けていると見られることも少なくありません。

開発チームが使う技術やスタックに制限を設ける必要がある場合は、セキュリティチームなどが十分に支援する、選択肢のある舗装路（paved road）を用意することが重要です。たとえば、セキュリティチームなどが十分にテストしたゴールデンコンテナイメージを用意し、開発者がそこから選んで構築できるようにするのは一般的な方法です。選択肢を提供し、それが舗装路として機能すれば、チームのセキュリティ維持を支援しながら、妨げとは見なされなくなります。

チーム間の可視性と透明性

アプリケーション、パイプライン、プロセスのセキュリティ態勢を可視化することは、チームや事業が抱えるリスクやエクスポージャーを特定する第一歩です。しかし、見つかった問題に対処しなければ、可視化しても意味がありません。この調査では、説明責任を示すスコアカードやレポートにセキュリティ態勢を定期的にまとめるために可視性を活用していたことが、開発者による導入を成功させた決定的な要因の一つだと分かりました。

導入に最も成功した組織のスコアカードでは、セキュリティだけでなく、機能開発、信頼性、パフォーマンスなど多くの側面を扱っていました。スコアカードは毎月作成され、脆弱性の件数、セキュリティツールの導入状況、プロジェクトのテスト指標、教育の進捗など、さまざまな運用指標を示していました。特に重要なのは、各社がスコアカードに含める指標を事業目標と一致させていたことです。ここから、スコアカードがどのように活用されたかを詳しく見ていきましょう。

優先順位付けと正当性の説明

セキュリティを含むビジネス指標を網羅したスコアカードがあれば、今最優先で取り組むべきことがセキュリティなのか、それとも先に対処すべきより大きな課題がほかにあるのかを簡単に把握できます。セキュリティ以外の項目も評価することが重要です。手元にあるすべてのデータを踏まえてこそ、十分な情報に基づいた判断ができます。

スコアカードはさまざまなレベルに合わせて作成し、見る人に応じてデータを調整する必要があります。たとえば、経営幹部が求めるのはチームリーダーよりも概要的な情報であり、全体的なビジネス目標との結び付きもより重視します。経営陣は、事業としてより注力すべき領域を示すレポートの結果に基づいて、優先事項を調整できます。一方、チームが知りたいのは、どこにもっと時間を割くべきか、そして自分たちのスコアが組織のほかのチームと比べてどうなのかです。

こうしたデータを活用すれば、開発者やチームは今後のスプリントで取り組むべきことをより適切に優先順位付けでき、その理由も明確にできます。特定のセキュリティ対策に注力する理由を尋ねられたときには、主観的な説明ではなく、客観的なスコアカードを提示することが重要です。

スコアカードの一環として、セキュリティチームは開発チームに具体的な優先順位付けの推奨事項も提示する必要があります。たとえば、最大の効果を得るために優先して対処すべき上位の脆弱性（または脆弱性の種類）をリストアップできます。

説明責任

セキュリティを優先事項にするには、組織の上から下まで、全員が説明責任を果たす必要があります。CTOはCEOに、エンジニアリング担当副社長はCTOに、マネージャーは副社長に、そして最終的にはエンジニアに至るまで、それぞれが上位の役職に対して責任を負います。全員がセキュリティを重視する理由を持てば、セキュリティはあらゆる役割における標準的な取り組みとして定着します。

幸い、スコアカードは適切な人々に期待される基準への説明責任を促す、簡単で効果的な方法です。スコアカードを公開すれば、組織の誰もが、問題のある状態にあるのか、正しい方向へ進んでいるのかをすぐに把握できます。また、定められたしきい値に達したときには、特定の指標に責任を持つ人が、原因や背景、考えられる解決策を特定できます。

セキュリティの優先順位付けで明らかになったのと同様に、セキュリティに関する説明責任は組織のトップにまで及ぶ必要があります。そうでなければ、セキュリティがビジネスにとって重要であり、開発チームにとっても重要であるべきだというメッセージは大きく薄れ、賛同も得られなくなります。

開発者の価値観とゲーミフィケーションを活用する

開発者は一般に、正常に動作するだけでなく、高速で、信頼性が高く、安全なアプリケーションを提供することを重視します。望む水準のコードを提供するうえで妨げとなる要因は数多くありますが、最終的には自分たちの成果物に誇りを持っています。スコアカードは、可能な限り優れたコードを届けたいという意欲をゲーミフィケーションによって高め、罰則ではなく報奨を軸にした説明責任へと変える効果的な手段です。

開発チームがプロジェクトの状況を把握できるようにすることは、順調に進んでいる点や改善している点だけでなく、苦戦している点や遅れが生じている点を示すうえで有効です。スコアカードが部門内で最下位だったり、事業部門や会社全体の平均を大きく下回ったりすると、開発者やチームの誇りが傷つくことがあります。自然と状況を改善したくなるものですが、まずはその事実を認識してもらう必要があります。

ゲーミフィケーションは、適切に実施すれば効果を発揮します。どのように進めるかは会社の文化に大きく左右されますが、チーム間でスコアカードを共有し、状況を可視化することで、ゲーミフィケーションへの反応が生まれます。最下位のチームになりたい人はいませんし、自分たちのスコアカードが向上し、チーム内の平均を上回ったり、部門内で上位に入ったりするのを目にするのはうれしいものです。同じくらい重要なのが、告知やディスカッションを通じてアイデアや成功事例を共有することです。こうした共有をきっかけに、チームがそのアイデアを再現したり、自分たちの領域でさらに発展させたりする新たな取り組みが生まれます。