SnykとIntuitのラウンドテーブル：サイロを解消し、セキュリティと開発者のコミュニティを活性化する

先日、SnykとIntuitのラウンドテーブルに参加しました。とても有意義なセッションだったので、洞察に富んだ議論や得られた学びを共有したいと思い、この記事を書きました。まずは、セッションを見事に表現したこちらのイラストをご覧ください。要点をまとめると、今回のセッションで得た主な学びは次のとおりです。

• 手戻りを防ぐなど、開発者が業務を進めるうえで役立つものとして、セキュリティタスクを提示する。

• 開発者が使いたいと思うツールを提供し、修正が最も簡単な選択肢になるよう取り組む。

• すべての開発者をセキュリティの専門家にしようとせず、もっと学びたい人に注力する。

• チャンピオンプログラムへの参加は任意とし、報酬や評価、メリットを通じてコミュニティの自発的な成長を促す。

• 違反がなかったことではなく、達成したことを測定する。

• 良い取り組みをしているチームの成功事例を共有し、さらなる成功につなげる。

開発者はそもそもセキュリティに関心があるのでしょうか？

議論は、開発者の大半はセキュリティに関心がないという衝撃的な発言から始まりました。セキュリティは追加の作業と見なされがちで、たとえば機能をリリースしたときのような称賛を得られるわけではありません。もちろん、開発者が正しいことをしたくないという意味ではありません。ほとんどの場合、開発者は正しいことをしたいと思っています。では、セキュリティをもっと魅力的にするにはどうすればよいのでしょうか。

開発者をセキュリティから遠ざけるもう一つの要因は、使われる用語です。SCA、SAST、DAST、RASPなど、一般的な開発者にはなじみのない専門用語が使われると、開発者の作業は難しくなり、混乱を招きます。セキュリティチームには通じる3文字や4文字の略語をかみ砕き、開発者にも理解しやすくすることが重要です。

では、開発者にセキュリティを魅力的に感じてもらうにはどうすればよいでしょうか？

開発者のセキュリティを強化するために、次のような提案がありました。

• 手戻りを防ぐなど、開発者の役に立つ方法で提示する。

• 修正が最も簡単な選択肢になるよう取り組む。

• 開発者が使いたいと思うツールを選ぶ。

手戻りを防ぐ

参加者の間で特に好評だった提案の一つは、共感を得られる形でセキュリティを提示することでした。開発者は誰でも手戻りを嫌います。手戻りを防ぐための手段としてセキュリティを位置づければ、セキュリティそのものを語るのではなく、後でセキュリティの問題を修正するための大幅な手戻りを避けるために、早い段階で何をすべきかを話し合えます。

セキュリティ対策を最も簡単な選択肢にする

もちろん、セキュリティの問題を未然に防ぐことは非常に重要です。対応にはコストがかかるだけでなく、開発者が避けたいプロジェクトの汚点にもなります。こうした反応を防ぐには、理解しやすいポリシーと、セキュリティに関する自然なフィードバックループを実現する可視性を提供し、開発者がミスをしにくくすることが重要です。修正を避けるのではなく、修正を促す、最も抵抗の少ない道筋を用意しましょう。

開発者を第一に考えたツール

もちろん、開発者がセキュリティの問題を発見し、修正するうえで、ツールも重要な役割を果たします。IntuitのVlad Nikolov氏が取り上げた重要なポイントは、開発者が自分たちでセキュリティツールを選べるようにしていることです。人は貢献や当事者意識を感じたいものです。Vlad氏は、IntuitにSnykが導入された経緯について、開発チームが使いたいツールとしてSnykをセキュリティチームに提案したと語りました。

開発者への教育をより効果的にするには？

まず認識しておきたい重要な点をいくつか紹介します。

• 学校ではソフトウェア開発の一環としてセキュリティを教えていないため、最初からハードルがあります。

• すべての開発者を専門家にしようとせず、もっと学びたい人に注力する。

セキュリティ教育

セキュリティを開発者の日常業務に取り入れるには、開発プロセスやソフトウェア開発の考え方に自然に組み込まれている必要があります。大学や専門学校で学ぶ開発者は、ソフトウェア開発を学ぶ際に、OWASP Top Tenやセキュアな開発・設計の原則について教わる機会がほとんどないという指摘がありました。ソフトウェア開発プロセスにセキュリティを真に組み込むには、学校でソフトウェア開発とともにセキュリティを教え、エンジニアがセキュアコーディングをソフトウェア開発全般の一部として捉えられるようにする必要があります。

個人ではなく、チーム全体で幅広いセキュリティ知識を身につける

とはいえ、ラウンドテーブルの議論は、開発者はセキュリティにあまり関心がないという話から始まったのではなかったでしょうか。セキュリティが常に最優先事項ではなく、学びたいと思っているとは限らない中で、開発チームがセキュリティ対策について十分な知識を持つにはどうすればよいのでしょうか。重要なのは、開発チームに求めるセキュリティ知識の深さを見極めることです。開発者がセキュリティの専門家になる必要はありませんが、いくつかの分野で適切に対応できる力は必要です。たとえば脅威モデリングが挙げられます。「もしこうなったら？」と開発者が問いかけることで、セキュリティリスクを減らすために必要な適切な処理の流れを考えられるようになります。

セキュリティチャンピオンプログラムで好奇心を育む

このテーマから得た大きな学びは、次の2つです。

• セキュリティに自然な好奇心を持ち、もっと学びたいと考えている開発者と時間をかけて取り組む。

• チャンピオンプログラムへの参加は任意とし、報酬や評価、メリットを通じてコミュニティの自発的な成長を促す。

好奇心を専門知識につなげる

開発者にはいくつかのタイプがいることを認識する必要があります。セキュリティに関心があり、密接に連携したい人と、必要に応じてセキュリティに取り組む人です。後者は、タスクを完了するために必要最低限のことを行います。そのため、実施すべきことのハードルを下げ、セキュリティプロセスを簡素化する必要があります。一方、セキュリティに関心がある人には、その好奇心を育み、活かすよう取り組むべきです。セキュリティチャンピオンプログラムを通じて支援することも考えられます。

セキュリティチャンピオンは自発的な参加者であるべき

セキュリティチャンピオンプログラムへの参加は任意であるべきだという点で、グループの意見は一致しました。セキュリティチームにとって、このプログラムは、参加意欲のあるメンバーを分散した開発チームから集め、セキュリティの協力者同士をつなぐ優れた方法です。うまく運営すれば、プログラムのメンバーが得ているメリットや報酬、評価を知り、参加したい人が時間をかけて自然に集まってくる場になります。

成果を祝い、報いる

成果を祝い、関わった人に報いることは、参加者全員が賛同した重要なテーマでした。実現に向けたアイデアをいくつか紹介します。

• 違反がなかったことではなく、達成したことを測定する。

• 良い取り組みをしているチームの成功事例を共有し、さらなる成功につなげる。

• 運用上の測定指標にとどまらず、プロセスやセキュリティ態勢の導入などの成果も称える。

多くの組織が、プロジェクトのセキュリティを成功ではなく、セキュリティ違反の件数で測っているという指摘はもっともです。その主な理由は、さまざまな開発チームを通じて一貫して追跡しやすい指標だからです。しかし、このアプローチでは、プロジェクトでうまくいったことではなく、問題点に焦点が当たります。問題が少ないこと以外に、順調に進んでいると広い開発コミュニティにアピールできることはほとんどありません。

一方で、本当に注目したいのは、セキュリティ違反になる前に開発者が脆弱性を発見し、修正した回数です。これはセキュリティプログラムの成功を測る実質的な指標であり、セキュリティを高める行動を中心にKPIを設定できます。さらに、開発者やチームがセキュリティ態勢の向上に取り組んだ成果を認め、他の人にも同様の行動を促すために、こうした活動に報酬を与え、ゲーミフィケーションを取り入れるべきです。

言うは易く行うは難しです。こうした考えに全員が賛同していたのは心強い一方で、実際に取り組んでいる例を見つけるのは容易ではありませんでした。参加者からは、開発者にわかりやすい表現にするため、用語を見直すといった取り組みが挙がりました。また、脆弱性の修正に優れた成果を上げている開発者を紹介し、逸話に基づく励ましや評価を伝えることで、ほかの開発者にも見習ってもらい、セキュリティ意識を高める行動につなげることができます。

成果は必ずしも運用指標に限りません。たとえば、パイプラインやプロセスにおけるセキュリティの改善も成果として捉えられます。アイデアの一つとして挙がったのは、現在の自分やチームのセキュリティ態勢を示す評価制度と、変更・改善したい点をまとめた計画や方針を組み合わせる方法です。これにより、個人やチームがこれまでに歩んできた道のりや、その進捗も記録できます。

セキュリティ問題が発生しなかったことをどう測定するか？

KPIや測定指標を複雑にしすぎるのは簡単です。実現したい重要な指標の一つは、セキュリティ問題が発生しなかったことではないでしょうか。開発での手戻りを避けるには、手戻りを防ぐために何が行われたかを把握する必要があります。セキュリティに関する習慣を測定することは、問題の発見状況を知るうえで有効です。たとえば、適切な脅威モデリングを実践し、チーム自らセキュリティ上の脅威を特定できているかを確認します。

シフトレフトの効果を考えるには、まず右側から見るとよいでしょう。最終的に目指すのは、セキュリティリスクや脆弱性の少ない、より安全な本番環境です。左側でプロセスや習慣を導入できれば、右側の測定値や数値が下がるはずです。これにより、左側で導入した取り組みの効果と成功を示せます。セキュリティ指標を確認し、シフトレフト（開発者第一）のセキュリティを導入したうえで、もう一度指標を確認しましょう。次回の開催地はhttps://snyk.io/events/をご覧ください。今後開催される参加型ラウンドテーブルへの招待については、Snyk担当者までお問い合わせください。