開発者のセキュリティに対する意識を理解する

やるべきことだから取り組む

開発チームにセキュリティ対策を取り入れてもらうには、セキュリティを役割や目標の一部として期待されるものにするのが最善です。そうすることで、開発チームにセキュリティを優先する権限と手段が与えられます。このモデルでは、責任の所在を明確にすることが重要です。共有プロジェクトやレガシープロジェクトのセキュリティ責任を、別のチームが担っていると思い込むことがないようにしましょう。

やるべきことを知っているだけでは十分ではありません。チームがセキュリティ目標を達成できるよう支援するプロセスを整えることも同じくらい重要です。たとえば、テスト結果を可視化したり、開発者が新機能を実装した後に生じる追加の攻撃対象領域やリスクについて説明したりすることです。スコアカードによる可視性と透明性は、個々の開発者がワークフローの一環として確実に実行するために必要な説明責任を果たす助けになります。この方法は、複数のプロジェクトを渡り歩き、プロジェクトへの当事者意識や愛着を持ちにくい傾向がある外部委託チームにも特に効果的です。

やるべきことだから取り組む

とても良い理由なので、2回取り上げました。開発者が安全な開発をするべき理由には、もう一つあります。それは、正しいことだからです。開発者の中には、セキュリティを重視し、持続可能で安全なコーディングに個人的または職業的な誇りと責任を強く持つ人もいます。

正しい方法を、簡単に実行できる方法にする（いわゆる「舗装された道」）

開発者がセキュリティタスクを実行する際に障害となるものは、どれもそのタスクを完了できなくする可能性があります。障害には、知識不足、極端に遅いワークフロー、問題が多すぎて何から手を付ければよいかわからないことなどがあります。既存のワークフローにセキュリティを簡単に追加できるようにすることが、セキュリティ対策の導入を促す鍵です。

「舗装された道」アプローチを通じて標準的な手法の利用を促すことは、役立つ支援と実証済みのベストプラクティスを提供する優れた方法です。さらに、正確で最新のドキュメントやアドバイスを作成し、他の人が定期的に再利用・更新できるようにする機会も増えます。

「私たちはこの考え方を舗装された道と呼んでいます。もちろん、藪をかき分けて森の中を進むこともできます。でも、目的地まで続く滑らかに舗装された道があれば、そちらを選ぶでしょう。」

Netflix、セキュリティ担当VPのJason Chan氏が The Secure Developerで開発者への共感について語る

開発者が前に進むために何を必要としているかを考えてみましょう。スキャン、テスト、問題の特定は、修正に比べれば比較的簡単です。開発者が知りたいのは、依存関係グラフにある10個の脆弱性ではありません。依存関係を一つマイナーアップグレードすれば、リリースを妨げている問題を解決できるかどうかです。問題ではなく解決策に目を向けましょう。通常、解決策のリストのほうがずっと少ないはずです。

また、開発者が何に時間を使いたいのか、セキュリティの結果やアクションをどのように把握したいのかを十分に考慮しましょう。普段のワークフローから外れるものはすべて、実行することを覚えておかなければならない負担になります。既存のプロセスや基盤技術を理解する人が実装した、既存ワークフローとのインテグレーションは、優れた開発者体験の実現に役立ちます。結果を役立つものにし、フィードバックを明確で実行可能なものにし、ワークフローを迅速かつ簡単に保つことを意識しましょう。つまり、開発者への共感をもって実装することが大切です。

自動化、自動化、そして自動化

優れたDevOpsパイプラインは、高度に自動化されています。Snykの最近の調査では、自動化とシフトレフト型セキュリティプログラムの成功にも強い相関があることがわかりました。データによると、デプロイパイプラインを完全に自動化している組織は、SDLCに静的アプリケーションセキュリティテスト（SAST）やソフトウェア構成分析（SCA）ツールを導入する可能性が2倍高くなります。さらに、完全に自動化している組織は、セキュリティ問題を1日以内に修正する可能性が4倍以上、1週間以内に修正する可能性が2倍以上高いこともわかりました。

自動化を進めるほど、実行できるテストが増え、検出できる問題も増えることは明らかです。慎重に検討すれば、パイプラインにセキュリティガードレールとポリシーを追加し、注意と対応が必要な問題を可視化できます。インテグレーションテストなどの自動化をすでに実行している開発者にとって、これは非常になじみやすい方法です。

さらに、セキュリティを自動化することで、セキュリティチームと開発チームの間の摩擦も軽減されます。問題の修正を求めるのがチームや個人ではなく、プロセスになるためです。これにより、セキュリティチームは開発チームを支援し、専門知識を必要とする問題に協力できます。ボトルネックになったり、悪い知らせを伝える役になったりする必要はありません。

「必要なのは、適切なセキュリティツールをすべてDevOpsパイプラインに自動化して組み込むことだと思います。もっと早く取り組んでおけばよかったと思うことの一つです。開発者がコードの問題をできるだけ早く知ることができるよう、自動化する必要があります。コードをチェックインする時点で知らせたり、コードを書いているときにIDEで問題をすぐに検出するツールを使ったりできるなら、なおさらです。自動化を整えることが非常に重要です。製品のリリース直前に問題を修正しようとするのは、はるかに困難です。」

Intel Products Assurance and Security Toolsチームのセキュリティアーキテクト兼ディレクター、Ryan Ware氏

教育とセキュア開発の知識

開発チームにとって、教育は効果にばらつきがあります。特に、関係のない研修コースや教材を義務として受講させられ、その後に短い試験まで受ける必要がある場合はそうです。こうした研修は、教育コンプライアンスのチェックリストにチェックを付けるだけで終わってしまうことも少なくありません。

教育を開発者の日常業務に役立つものにし、バグ修正や、これまで以上に安全な開発につなげることで、セキュリティの導入を加速できます。コースや教育コンテンツは、開発者にとって価値があり、セキュリティの向上に役立ち、その効果をすぐに実感できるものでなければなりません。

教育について考える際は、チームがセキュア開発に集中するうえでどのように役立つかを検討しましょう。学んだことをどのような行動に移し、プロセスやワークフローに実際に適用できるかを考えてください。必要なときに適切な支援を提供できるよう、教育内容をどのように対象に合わせるかを検討しましょう。教育は技術だけでなく、プロセスや文化にも目を向ける必要があります。

セキュリティ教育を最大限に活用するためのヒントをご紹介します。

• 研修は、受講者が自ら受けたいと思えるほど魅力的な内容にしましょう。教育の質を高める簡単な方法は、パイロットプログラムを実施してフィードバックを集め、大規模に展開する前に調整することです。

• 開発チームによって攻撃対象領域が大きく異なる可能性があることを認識し、それぞれに関連するレッスンを提供しましょう。たとえば、ディレクトリトラバーサル攻撃はバックエンド開発者により関係が深いかもしれません。

• 脆弱性に関する研修では、対象チームに影響する脆弱性（該当する言語、フレームワーク、ライブラリなどに基づくもの）を取り上げましょう。同様のエコシステムを利用する他社で発生したインシデントを紹介すると、深刻な事態につながる可能性を示せます。

• 実際のセキュリティ問題を例として示すのは有効ですが、恐怖を主な動機づけに使うのは避けましょう。短期的には効果があるかもしれませんが、長期的な戦略にはなりません。ただし、事業に壊滅的な被害をもたらしかねないなど、本当に深刻なセキュリティ問題は例外です。

• スコアカードに教育項目を追加し、チームが教育を完了するよう説明責任を持たせましょう。

• 具体的な攻撃をどのように防ぐかに焦点を当てた教育にしましょう。脆弱性を説明するなら、実際に悪用できることを示します。パイプラインの一部を強化する方法を説明するなら、軽減できる攻撃対象領域を説明します。現実的で具体的な内容にしましょう。

• 開発者に実行してほしいタスクについては、必ずドキュメントを用意しましょう。開発者にドキュメントの有効性を検証してもらうか、さらに良い方法として、次の開発者やチームのために自分たちで作成してもらいましょう。ドキュメントはガードレールの代わりにはなりませんが、ガードレールについても記録しておく必要があります。

• レッドチームがインシデントを発見したら、それを関連性が高く現実的な教育を作る機会として活用しましょう。インシデントを深く掘り下げた情報を提供することで、現実のリスクを具体的に伝えられます。可能であれば、レッドチームを招いて質疑応答を行いましょう。

開発者がセキュリティを避けるのはなぜでしょうか？

開発者が安全なソフトウェアを構築するために時間を割く理由について説明してきました。しかし、それと同じくらい、あるいはそれ以上に重要なのは、安全なコードを届けるための追加作業に反発したり、避けたりする理由を理解することです。

摩擦

チームにおけるセキュリティ導入の段階や、最新の開発手法への習熟度によって、チームが感じる障壁は異なります。セキュリティ導入の初期段階にあるチームでは、プロセス変更の理由や価値が明確に伝わらないと反発が生じます。新しいプロセスは、開発チームやそのワークフローに過度な負担をかけず、共感に基づいたものでなければなりません。導入を促進するには、十分にコミュニケーションを取り、既存プロセスとのインテグレーションによって摩擦を最小限に抑え、可能であればツールを統合して複雑さを軽減しましょう。

「大きな課題の一つは、技術部門の主要なステークホルダーや開発者に、セキュリティの重要性と価値を本当に理解してもらうことだと思います。理想的には、すでに理解されているべきです。価値を見いだせなければ、開発者が何かに取り組む意欲を持つのは難しいでしょう。プロダクトオーナーや開発マネージャー、ソフトウェアエンジニアリングディレクターも同じです。セキュリティの価値に共感できなければ、機能開発よりも優先する動機は生まれません。」

PearsonのDevSecOpsリード、Nicholas Vinson氏

不信感

チームが長期にわたって継続できるプロセスには、価値を提供し、信頼を維持または獲得することが必要です。データ、ツール、プロセスへの信頼を失うと、チームはそれを障害とみなし、回避しようとします。たとえば、ツールやプロセスで誤検知が繰り返されると、開発者を落胆させたり苛立たせたりするだけでなく、信頼できるデータに基づく場合と比べて、実際の脆弱性や問題の結果を無視したり、誤りだと判断したりする可能性が高まります。

複雑さ

同様に、ツールが既存の問題を複雑にするだけで、問題の発見や解決に役立たなければ、開発者の作業が増えるだけです。脆弱性の存在を知ることは、問題の始まりにすぎません。開発者は、アプリ内のどこから、どのような経路で脆弱性にアクセスできるのか（たとえば、依存関係グラフのさまざまな経路）を特定する必要があります。修正できるかどうか、できる場合はどのように修正するかを、すぐに把握できなければなりません。開発者が求めているのは、直感的で具体的な手順を示し、迅速な解決を可能にするツールです。

責任の所在

作業がある人の手から離れても、別の人に引き継がれない理由の一つに、オーナーシップの問題があります。新しいプロジェクトや機能では、問題のあるコードに触れるのが特定のチームだけであれば、担当が明確な場合もあります。しかし、複数のチームが利用し、貢献している一方で、全体を所有するチームがない共通サービスがアプリケーションの一部だったらどうでしょうか。自分たちに直接影響しないバグやセキュリティ上の問題を、誰が引き受けるのでしょうか。多くのチームが利用するコンテナイメージも、よくある例です。各チームがそれぞれの機能開発に追われていると、こうした共有コードの問題は、担当者が名乗り出ないまま放置されがちです。

時間

もちろん、担当が明確でも、ワークフローに対応を組み込む時間を確保するという課題は残ります。コードをテストする自動化があっても、それは簡単な部分にすぎません。本当の作業は、開発者が結果を確認し、修正を行うことです。ツールの誤検知が多かったり、修正方法が明確でなかったり、自動で修正できなかったりすると、対応が後回しになる可能性が高まります。同様に、組織がセキュリティ修正や活動を優先しなければ、開発者はセキュリティチームからテストや修正を求められても、反発したり無視したりするでしょう。

説明責任

説明責任は、開発者がセキュリティ業務に取り組むべき理由の中核となる要素ですが、誰に対して責任を負うのかも同じくらい重要です。たとえば、チーム内のメンバーやセキュリティチャンピオン（開発者）、あるいは直属の上司から作業の実施を求められるほうが、開発者は取り組む意義を感じやすいでしょう。一方、明確な対処手段もないままセキュリティチームだけが責任を求めても、セキュリティを確保しなければならないという意識は薄れてしまいます。

手本となる存在の不足

人は周囲の人の行動を手本にします。ほかの人がセキュアな開発をしている姿や、ほかのチームがプロジェクトでセキュリティを優先している様子を目にしなければ、セキュリティタスクを無視することに周囲も合わせてしまいがちです。これを防ぐ方法はいくつかあります。たとえば、コードレビューでセキュリティを可視化し、セキュリティに関する質問を投げかけて、検討や注意を促すことです。もう一つの方法は、手本となる人をつくることです。

組織で増やしたい行動を実践した人を称えましょう。セキュリティを開発パイプラインに組み込んだり、セキュリティのバックログを減らしたりするうえで、チームが優れた成果を上げた事例や前進した点を紹介します。セキュリティの成果を称える取り組みは、エンジニアリング部門のリーダーシップチームが実施し、広く周知するとともに、ドキュメントや自動化などを通じてほかの人も繰り返し実践できるようにしましょう。