大規模環境におけるセキュリティ責任の運用：Twilioの視点

安全なソフトウェアを提供するためにDevSecOpsの実践を導入する組織が増えるなか、セキュリティ責任のあり方はこれまで以上に重要な課題となっています。Snykは最近、Twilioとラウンドテーブルを開催し、2021年におけるセキュリティ責任について話し合いました。

この記事では、SnykのPresident & Co-FounderであるGuy Podjarnyと、TwilioのProduct Security担当Senior ManagerであるYashvier Kosarajuによるディスカッションを振り返ります。TwilioのProduct Securityチームは、設計からデプロイまであらゆる段階でコードの安全性を確保するために、Snyk Open Sourceを活用しています。

誰が何を担うのか（開発チームかセキュリティチームか）を決める方法

企業がDevSecOpsのアプローチに移行する際、答えを出すべき重要な問いのひとつは、「実践やプロセスの観点から、開発チームとセキュリティチームはそれぞれ何を担うべきか」です。

スキャン、脅威モデリング、ペネトレーションテストなど、セキュリティに関する機能はセキュリティチームが担うべきです。また、セキュアなソフトウェア開発ライフサイクル（SSDLC）や企業セキュリティに関するプロセスも担当します。一方、開発チームはリスクを管理し、脆弱性を適切なタイミングで修正する責任を負うべきです。

とはいえKosaraju氏は、結果を出しやすくするために、セキュリティチームは使いやすい形でツールを提供すべきだと考えています。

「開発者を採用するときは、コードを書けるか、設計ができるか、アルゴリズムを理解しているかといった点を確認します」とKosaraju氏は言います。「これは悪いことではありませんが、採用プロセスでセキュリティの専門知識が最優先されることはほとんどありません。だからこそ、セキュリティに注力し、会社に関する判断を担う中核チームが重要なのです。」

最終的に、誰が何を担うかは経営陣が決定する必要があります。ただし、実践や制御策をアプリケーションに直接組み込む必要があるため、セキュリティチームには、開発者を支援する「卓越性のセンター」として機能する責任があります。

特定のプロセスを組織体制の中で誰が担うかを明確にすることも欠かせません。そうしなければ、脆弱性が大量に報告されても、修正を担当する事業部門が関与していないというリスク評価表ができあがってしまいます。最初からセキュリティ責任を明確に定義することで、具体的な行動につながります。

「自分たちは開発者であって、セキュリティ担当者ではない」という考え方を変える

開発者にセキュリティを取り入れてもらうことは、組織にとって簡単ではありません。導入を妨げる大きな要因として、可視性と使いやすさの2つが挙げられます。

まず、セキュリティには自然なフィードバックループがありません。そのため、脆弱性は解決されないまま蓄積し、事業に影響が出るほどの数に達してから対応されることがよくあります。企業はセキュリティ要件を明確に定め、すべての開発者に見えるようにする必要があります。

現実には、セキュリティは複雑すぎるのです。開発者に導入してもらうには、セキュリティをシンプルにする必要があります。企業がよく陥る失敗のひとつは、最初から多くのことに取り組みすぎることです。導入を始める際は、オープンソースセキュリティやソフトウェア構成分析（SCA）の導入など、早い段階で成果を出せる取り組みを探しましょう。

「現状と目指すべき姿を示し、継続的な改善の道筋を描くことが重要です。そのためには可視性が欠かせません」とKosaraju氏は言います。「また、役割の境界を定めることも重要です。たとえば、セキュリティチームが会社を守ると言うとき、それは修正すべきセキュリティ問題を見つけることなのか、それとも問題の修正まで行うことなのか。誰が何をするのか、責任の分担を明確にすることが不可欠です。」

コードレベルでは、Twilioはすべての開発者に各コードリポジトリへのYAMLファイルの追加を依頼し、責任の所在を明らかにするモデルを構築しました。各ファイルには、そのリポジトリのオーナーを特定するために必要な情報が含まれています。これにより、セキュリティチームは適切なキューにチケットを登録し、インシデントや脆弱性が発生した際にオーナーへ連絡できます。この仕組みにより、担当者を手作業で探す状態から、適切なチームをすぐに特定し、脆弱性管理を自動化できる状態へと移行できました。

開発者一人ひとりを対象にセキュリティを測定する

バグバウンティプログラムから始めることは、セキュリティツールのROIを把握する優れた方法です。プログラムを導入したら、SDLCのさまざまな段階にツールを組み込み、バグバウンティへの報告件数を減らしていくことができます。報告件数が減れば、チームはシフトレフトセキュリティの実践に取り組めるようになります。

「新しいツールを導入すると、バグの数が必ず一時的に増えることを覚えておくことが大切です」とKosaraju氏は言います。「セキュリティツールや機能の不足を明らかにすることが重要です。セキュリティチームも完璧ではありません。しかし、その現実を認めることで、セキュリティの考え方を取り入れながら、会社をより安全にするために全員が協力しているというメッセージを伝えられます。」

開発者が脆弱性を全体的な可視性と関連づけて捉えるには、重大な脆弱性がキューに残っている期間を確認するのが最適です。これは、チームがどれだけ迅速に脆弱性を修正できているかを示す理想的な指標です。たとえば、セキュリティチームがTool Xを導入し、重大な脆弱性として30件を検出したとします。エンジニアリングチームが2週間でそのうち29件を修正できたなら、これは継続的に追跡する価値のある優れた指標です。

セキュリティ責任のあり方は毎年変化し続けています。Snykは業界のセキュリティ専門家からさまざまな視点を得るため、定期的にウェビナーを開催しています。こうしたラウンドテーブルを通じて、Snykはアプリケーションセキュリティチームや開発者のニーズを理解し、Twilioのような組織が必要とするセキュリティに合わせて、企業が製品を進化させ続けられるよう支援しています。