REIがDevSecOps文化を築いた方法と、Snykの支援

著者

Brian Piper

2024年2月27日

10 分で読めます

数年前、REIはデジタルトランスフォーメーションとクラウド移行に着手し、オンプレミスの開発環境をAWSへ移行しました。しかし、REIの開発チームが移行を開始する一方で、セキュリティ部門はアプリケーションセキュリティが追いついていないことに気づきました。そこでREIは、AppSecを成功させるための適切なセキュリティツールと文化的な変革を見極める取り組みに着手しました。

REIのサイバーセキュリティエンジニアリングおよびリスク管理部門でリードセキュリティエンジニアを務めるDan Ngoと、SnykのField CTOであるClinton Hergetは、AWS re:Invent 2023のセッションで、REIのチームが開発部門全体に強固なセキュリティ文化を築いた方法について語り合いました。2人の取り組みについて詳しく知りたい方は、ぜひ続きをお読みいただき、以下の動画全編をご覧ください。

REIがAppSecプログラムを立ち上げた理由

DanがREIに入社した頃、同社はクラウド移行を含むデジタルトランスフォーメーションを進めていました。当時、セキュリティは開発者のワークフローからほぼ切り離され、エンドポイントやメールのセキュリティなど、別の領域に重点を置いていました。アプリケーションセキュリティの取り組みもいくつかありましたが、その多くは開発チームごとに異なる方法でアプリケーションを保護するものでした。各チームは主に、率先して取り組む少数のセキュリティチャンピオンに頼っていました。しかし、チャンピオンのセキュリティ実践に関する経験にはばらつきがあり、組織全体で一貫性を保てていませんでした。

Danは着任後、開発者にセキュリティのために何をしているか尋ねました。開発者は、セキュリティレポートを作成するためにいくつかのツールを使っているものの、結果はほとんど確認していないと答えました。

Danによると、「セキュリティを意識し、コンプライアンス対応のためにセキュリティスキャンを導入しているエンジニアや開発者もいました。しかし、そこから実質的なメリットは得られていませんでした。」

Danとチームは、アプリケーションのモダナイゼーションとともに成長できる、強固なセキュリティ基盤を確立する必要がありました。その基盤には、適切なツール、文化、プロセスの組み合わせが欠かせないと考えていました。最終的な目標は、セキュリティを開発の早い段階に組み込み、開発者やエンジニアをセキュリティの取り組みに巻き込み、組織全体でDevSecOpsを実践することでした。

REIにおけるSnykツールの活用方法

他チームとの強固な関係づくりに取り組む中で、Danのチームは脆弱性の検出と修正に適したツールを選ぶ必要があると考えていました。複数のツールを試した結果、Snykを導入しました。開発者は、Snyk Open Sourceでオープンソースの脆弱性を可視化できることや、Snyk Codeによるコード修正の提案を高く評価しました。また、プラットフォームエンジニアリングチームは、REIの既存ツールやAWSの基盤となるクラウド環境との連携が最も優れていたことから、Snykを選びました。

DevSecOps文化を築くためのREIのヒント

Danのチームは、エンジニアリング部門と開発部門の連携を促進する中で、うまくいった手法とそうでない手法を見つけました。目指す支持とセキュリティ成果を得るには、最終的に文化を変革する必要がありました。

Snykのツールを活用して文化を築いたDanの経験から得られた、特に重要な3つのポイントをご紹介します。

他チームの優先事項を深く理解し、信頼関係を築く

セキュリティプロセスの初期段階で、REIは開発者の視点を理解する時間を取らずに、新しい静的コード解析製品を迅速に導入しようとしました。この導入はうまくいきませんでした。Danによると、既存のパイプラインと連携できなかったため、開発者はツールに反発しました。その結果、両チームの間に大きな摩擦が生じました。

フィードバックを集めたDanのチームは、開発チームやエンジニアリングチームの既存のワークフローに逆らうのではなく、それに合わせて取り組む必要があると気づきました。REIの既存プラットフォームと各チームを詳しく調査し、それらと連携して使えるツールやプロセスの導入を目指しました。

Danは他チームの視点を真に理解するため、サイト信頼性エンジニアリングチームに深く関わり、多くの時間を費やして、既存のプロセスや優先事項について学びました。

「コードへの貢献を通じて、マイクロサービスの仕組みや、インフラエンジニアの仕事の進め方を理解することに努めました。そして信頼関係を築いたうえで、彼らに新たなセキュリティの考え方を紹介していきました。」

継続的な成長を受け入れる

対談の中でDanは、チームが新しいことに挑戦して失敗し、そこから学んだ経験をいくつか紹介しました。最初から完璧を求めるのではなく、まず始めて、時間をかけてプロセスを改善するという考え方をチームで実践しています。

継続的に成長する姿勢の一例として、チームはSnykの導入時に相談会を開きました。このオープンな対話とSnykのアラートを通じて、多くのセキュリティスキャンの検出結果を開発者自身では修正できないことがわかりました。実際、脆弱性はプラットフォームエンジニアリングチームが管理するCRAMPONというライブラリに含まれていました。一部の開発者は、このフレームワークの古いバージョンを使っていました。こうした課題を受けて、Danのチームは改善に取り組むことができました。

「現在は非推奨化ポリシーを設けています」とDanは語ります。「SLAもあります。CRAMPONフレームワークの最低バージョンを定め、その基準を開発者に伝える取り組みも進めています。社内ツールの最低要件として、どのバージョンを使う必要があるのかを理解してもらうためです。」

修正の担当者を特定し、責任を明確にする

AppSecに対する包括的で実行可能なアプローチの一環として、Danはレガシーコードへの対処方法も見つけたいと考えていました。重要なのは、レガシーソフトウェアの各部分をどのチームが担当するのか明確にすることでした。

モノリスの大部分を分解したことで、チームはレガシーコードの大半について、社内での担当チームを把握できるようになりました。Snykは依存関係の特定にも役立ちました。現在、セキュリティチームはコードの担当者を明確に把握し、適切なグループと連携して修正に取り組めます。明確な担当者がいないままレガシーモノリスに残っているコードやサービスについては、セキュリティチームがSnykを使って関連するセキュリティ問題に直接対処しています。これにより開発者からの信頼が深まり、開発者自身が問題を確認するよう促せています。

REIのアプリケーションセキュリティにおける成果

プロセスとツールを適切に選んだことで、Danのチームと開発チーム、プラットフォームエンジニアリングチームの連携は大きく深まりました。プログラムの成熟度を高める中で、Danの最大の目標は、開発者がアプリケーションの脆弱性を理解して状況に応じて判断し、REIが定めるSLA、特に平均修復時間（MTTF）に沿って修正の優先順位を決め、実装できるようにすることです。Snykは、パイプラインの早い段階で脆弱性を見つけ、開発者が迅速に修正できるリソースを提供することで、この目標の達成を支援しています。

「Snykが問題を検出したことで、開発者がアプリケーションに修正をデプロイする姿を見られるのは、強固なプロセスとセキュリティチーム・開発チーム間の信頼関係を築く正しい道を進んでいる、と実感できるとてもよい兆候です。」

以下のAWS re:Inventのプレゼンテーションで、REIとのパートナーシップについて詳しくご覧ください。開発者を第一に考えたSnykのセキュリティプラットフォームをお試しになりたい場合は、AWS MarketplaceからSnykの無料アカウントに登録するか、Snykアプリから直接登録できます。

動画：AWS re:Invent 2023 - REIがDevSecOps文化を最初から築いた方法

AWS re:Invent 2023 - How REI built a DevSecOps culture from the start (DOP103)