「yamoryなら信頼できる」品質と開発スピードを両立した脆弱性管理 - 株式会社アルファドライブ
株式会社アルファドライブ
業種：コンサルティング / SaaS
事業概要：新規事業の創出と開発支援を行い、新規事業開発を支える SaaS「Incubation Suite」や、人材育成と組織改革のプラットフォーム「NewsPicks Enterprise」などを提供
新規事業の創出と開発に向けた組織活性化や人材育成を行う株式会社アルファドライブは 2018 年創業。「新規事業が生まれ続ける」組織設計や制度作りを行っています。また、新規事業開発支援サービス「Incubation Suite」などの SaaS の自社開発を積極的に行っており、脆弱性管理クラウド yamory を CI/CD ツールと統合して、開発チーム全体で 2022 年 5 月から活用しています。
取材時に「私自身が yamory が好きでファン」と破顔一笑した、執行役員 CTO / ニューズピックス技術フェローの赤澤氏にお話をうかがいました。
💡 課題背景
- アルファドライブではプロダクト開発の初期フェーズからいかに「セキュリティ」と「オブザーバビリティ（可観測性）」を高めるかを極めて重要な課題と認識していた
- 開発の後工程でセキュリティ品質を上げようとすると手戻りが発生するため、初期段階からセキュリティを担保するツールを探していた
- 定期的に行う脆弱性診断への対応は CVSS のスコアをもとに対応方針を決定していたが、現実の深刻度を判断する基準は CVSS 以外にもあると考えていた
🙌 導入の決め手・導入効果
- セキュリティを保証して状態を可視化できる yamory は、アルファドライブが重視する「セキュリティ」と「オブザーバビリティ」の確保に有効だった
- CVSS のスコアだけでなく、アクセスパスの存在や攻撃コードの流通などから判断して現実の深刻度に従ってトリアージを行う仕組みが信頼できた
- 2021 年 12 月、Apache Log4j の脆弱性が大きな話題になった際に、yamory の公式 Twitter から配信された情報の速度と正確さのバランスを見て、サービスの前提となる企業と組織への信頼を強く感じた
🖥 活用シーン
- GitHub で Pull Request を上げる際に yamory をコールしてレビューを行い、脆弱性があれば Slack に通知させている
- 見つかった脆弱性は、yamory のダッシュボードが提案するトリアージに従って修正している
――課題背景や、導入の目的、経緯をお聞かせください
アルファドライブは「品質と（開発）スピードはトレードオフではない」という前提で、理想と現実を分けて考えるのではなく、丁寧に理想を追いかけることこそが現実解だと考え、プロダクト開発を行っています。
品質を犠牲にすればアジャイル開発は成立しません。「アジャイルソフトウェア開発宣言」にある「動くソフトウェア（Working Software）」とは、「品質を犠牲にして何とか動いている状態」などではなく、「機能を含めた品質を維持し、ユーザーに価値提供をしている状態」と考えています。
アルファドライブが開発の初期段階から特に留意するふたつの「-ity（事物の性質を現す英語の接尾辞）」があり、それは「Security（セキュリティ）」と「Observability（オブザーバビリティ：可観測性）」です。このふたつが担保されていない開発プロジェクトやソフトウェアを、我々は「アウトオブコントロール」、すなわち自分たちが制御できない状態に陥っていると考えています。
しかし、開発の後工程になってから、下がってしまった品質を上げようとすると、初期設計にまで手戻りが発生することすらあります。そのため、短期的にも中長期的にも、開発の初期フェーズから「セキュリティ」と「オブザーバビリティ」をしっかりと確保してくれるツールがないかと探して、最終的にいくつかの候補に絞り込んでいたとき、世界で Log4j の脆弱性が大きな話題になりました。
――導入の決め手は何だったのでしょうか？
私個人にとって脆弱性管理とは「面倒で工数がかかるけれど、それでも必ず対応しなければならないもの」です。それをこんなにスマートにサービス化した yamory を見つけたときは、素直に素晴らしいと思いました。
セキュリティを保証して、どういう状態であるかを可視化してくれる yamory は、アルファドライブが留意する「セキュリティ」と「オブザーバビリティ」というふたつの「-ity」をしっかりと確保してくれるツールであると開発チームが認識しています。これが導入の決め手のひとつです。
また、CVSS のスコアを原則にしながらも、そこに脅威分析アナリストが調査した、アクセスパスの存在や攻撃コードの流通なども加味して判断を行い、最終的な深刻度をつけるというのがすごく合理的だと思いました。「これ（yamory）を作っている人は信頼できる。一度話をしてみたい」と思いました。これが決め手のふたつめです。
さまざまな脆弱性管理ツールを調査して、yamory を含むいくつかの候補に絞り込んでいた時期に、Log4j の脆弱性が報告され、グローバルで大きな話題になりました。私は Twitter を情報収集ツールとして活用していて、さまざまなベンダーや専門家のアカウントをフォローしており、そのときも Log4j の情報を複数ソースから集めまくりました。
そのときに、どんなメディアやベンダーのアカウントよりも速報性に優れ、しかし同時に正確性というバランスを決して失わない情報発信元が yamory の公式 Twitter アカウントでした。「サービスの前提となる会社や組織が信頼できる」本心でそう思えました。個人的にはこれが導入することの決定打と言えるかもしれません。
――導入効果や導入してよかった点を教えてください
現在は、世の中のあらゆる公開サービスやサーバが常時なんらかの攻撃を受けている状態で、それは WAF などのログを見ればわかります。対象のサービスや企業に何 1 つ私怨がなくとも、言うなれば「ドアを見かけたらとりあえず開ける」「開いたら中のものを持ち出す」という人がサイバーの世界にはあふれており、狙われることにいまや理由などありません。
セキュリティは、サービスやブランドの「ノックアウトファクター（このサービスを選ばない、使わないとユーザーに判断させる要因）」になりうるものであり、サービスだけでなく事業継続にも関わると思っています。今後も yamory を活用して開発者全員が「セキュリティ」と「オブザーバビリティ」に、開発と運用の両面から対応していきたいと思います。
――今後のyamoryに期待することや活用シーンを教えてください
アルファドライブでは、脆弱性を特定する Amazon ECR Image scanning と yamory、そして専門企業による定期的なセキュリティ診断をそれぞれ併行して活用しています。
yamory は Image scanning なら数千件見つかる脆弱性を「すぐ対応すべき」数件に絞り込むのに役立ちますし、OSS ライブラリの間接依存まで検知するという圧倒的強みがあります。
専門セキュリティ企業によるペネトレーションテストなどのセキュリティ診断は、ビジネスロジックや設定漏れなど、 yamory での対応を踏まえた上での総合的な攻撃パターンの検証であると考えて行っています。