パネルの振り返り：Corey Quinnと学ぶ、セキュリティ習慣の改善

12月8日、SnykのField CTOであるClinton HergetとSimon Mapleが、The Duckbill GroupのChief Cloud Economistであり、ポッドキャストのホスト、「Last Week in AWS」のキュレーター、そして皮肉の効いたツイートで知られるCorey Quinnと語り合いました。

会話は、AWS re:Inventでコーヒーを買うために1時間並んだ話から、Coreyが「SBOMは幻想だ」と断言した場面まで、楽しい展開が盛りだくさんでした（この発言にはもう少し背景があります……続きを読む）。このブログでは特に印象的だった話題をいくつか紹介します。Corey Quinnらしい発言をすべて聞きたい方は、こちらからパネル全編をご覧ください。

AWS re:Invent 2022の振り返り

AWS re:Invent 2022が終わったばかりということで、CoreyとClintonは、特に印象に残ったことをいくつか振り返りました。Coreyは、セッションへの参加より、人と会うことを優先するのが大切だと強調しました。AWS re:Inventの開催中に使える時間には限りがあり、Coreyはセッションに座っているより、AWSの関係者と会うことを楽しんでいます。セッションはカンファレンス後にオンデマンドで視聴できますが、AWSの専門家と直接話せる機会はそう多くありません。

Clintonは、Amazon Web Servicesが発表したOpen Cybersecurity Schema Framework（OCSF）への取り組みに期待を寄せました。セキュリティフレームワークを標準化することで、AWSはアプリケーションセキュリティを記述するための、相互運用可能で機械可読な言語の標準化を先導しています。Clintonは、これが共通のリスクについて業界全体でより良い対話を実現するための第一歩になると考えています。

2022年を振り返る：AWSセキュリティの課題

Corey QuinnとClinton Hergetは2022年を振り返り、新年に向けて対処すべきAWSセキュリティの「課題」をいくつか取り上げました。主なものは次のとおりです。

開発環境と本番環境の隔たり

Clintonによると、今日のソフトウェア開発における重大な問題の一つは、開発環境と本番環境の隔たりです。クラウド上のすべてがコードである以上、セキュリティリスクへの対処もコード上で行う必要があります。Clintonはこう話します。「運用担当者として、『EKSクラスターのPodにLog4Jが見つかりました。修正してください』という、目立つ赤い警告を受け取ります。でも、その次はどうすればいいのでしょうか。その通知を受けて、どのファイルやGitリポジトリを変更すればよいのかを機械可読な形で特定し、自動化する方法がありません。」

ソフトウェアサプライチェーンへの過剰な信頼

さらに、ソフトウェア開発チームは2022年、ソフトウェアサプライチェーンに含まれるコンポーネントを過信していました。オープンソースソフトウェアやその依存関係をすべて安全だと決めつけるのではなく、サードパーティ製コンポーネントが実際に安全に使えるかを検証する必要があります。

不十分なSBOM

Coreyは、現在のソフトウェア部品表（SBOM）では不十分だとも指摘しました。彼によると、現代のアプリケーションが持つ相互依存関係を適切に表現できていません。「依存関係の依存関係の、そのまた依存関係」と、推移的依存関係をたどっていっても、アプリに潜むサードパーティリスクの全容を把握できないのです。

今日のセキュリティ課題への解決策

ClintonとCoreyは、新年を迎えるにあたり、企業がこうした「2022年の課題」をどう捉え、対処すべきかについても話し合いました。主な話題は次のとおりです。

SBOMを他のベストプラクティスで補う

では、SBOMの運用を改善するにはどうすればよいのでしょうか。Corey Quinnは冗談交じりに、「これを本当に解決するには、人間にパッチを適用する必要がある」と話しました。

つまり、ソフトウェアサプライチェーン全体の構成を書き出すだけでは、セキュリティの問題は解決しません。組織文化を変え、人々がセキュリティの問題を解決できるようにすることが必要です。その重要な取り組みの一つが、セキュリティアラートを減らすことです。ノイズを抑え、チームがSBOMの中から本当に重要な問題をトリアージできるようにします。

Clintonはまた、組織はオープンソースの利用をそれほど恥じる必要はないと付け加えました。オープンソースの利用は問題なく、ビジネスの成功を脅かすものではないと理解すれば、どの共有コンポーネントをどこで使っているのか、より透明性を高められます。

組織の既存プロセスを深く理解する

IaC、クラウド、ソースコードはどのように関係していますか？ セキュリティチームは開発者とどのように連携し、その逆はどうでしょうか？それぞれの担当者は、日々どのようなコンテキストを見ているのでしょうか？ClintonとCoreyは、一歩引いてこうした問いに答えることが重要だと強調しました。各部門がリスクをどう捉え、対処するかに大きな違いをもたらします。

Coreyはまた、「自分が置かれている状況を理解し、自分にとって妥当な判断をする」という以上の助言をすることには、「とても慎重だ」と述べました。だからこそ、組織はより深く問いかけ、自社に合ったセキュリティのベストプラクティスを見つける必要があります。

開発チームのコンテキストに逆らわず、活用する

セキュリティは、問題が起きてから対応することの多い分野です。Coreyによると、セキュリティ対策は必要不可欠ではあるものの、目に見える形でビジネスを前進させるものではありません。そのため、後回しにされがちです。多くの部門がセキュリティをそのように捉えているとすれば、チームはセキュリティ対策をできる限り負担の少ないものにする必要があります。

SDLCのセキュリティ対策は、手作業をできる限り減らして実施すべきです。特に、セキュリティのベストプラクティスを開発者が実践できるようにするには、開発者のコンテキストに寄り添い、日々の業務で何を扱っているかを理解することが大切です。

新年、新たなAWSセキュリティの可能性

ここで紹介したのは、CoreyとClintonが話し合った内容のほんの一部です。開発者を第一に考えるセキュリティへの注力から、ソフトウェアサプライチェーンの透明性向上まで、2023年に向けたAWSセキュリティのさまざまな可能性について話しました。

対談の全編はこちらからご覧ください。また、Snykの開発者向けセキュリティプラットフォームが、2023年のセキュリティプログラムの拡大にどのように役立つかをご覧ください。