前エントリーでは組織として社内へ脆弱性対策への取り組みの一環として、yamoryという脆弱性管理サービスを導入するまでをお伝えしました。 今回はyamoryを実践で実際に使ってみて、各々が個別に最適して工夫した所や所感をご紹介したいと思います。
最初はImmediate（即時に影響を受ける可能性）を無くすところから
１つ目の適用プロジェクトの事例です。
スタートアップ系の案件となります。ビジネスモデルを立証や確立を目指していくところから始めるので、コストも限られていて機能実装のバランス感覚が非常に重要になってきます。
プロジェクトが始まってから数年経過していますが、現在もユーザを獲得したり市場の要望に応えていくフェーズの真っ只中で、たくさんのモジュールや個別対応などシステムも大きくなってきています。
その中には初期頃に作ったモジュールも含まれており、特段理由がなければライブラリを最新バージョンにはアップグレードせず、当時の最新版を利用しているモノもありました。
社内にyamoryが導入されたということで、試しにyamoryを使ってスキャンしてみたところ、幾つかキャッチできていなかった危険な脆弱性が見つかり、取り急ぎ対応しました。
やはり、逐一開発チームだけで脆弱性情報をキャッチしていくには時間の都合上無理があるとは感じていたので、yamoryがあると非常に助かるということで、チーム内で相談して本格導入が決まりました。
yamoryを導入すれば脆弱性情報が公開されて即時に対処できるようになるので、対応基準とフローを検討することにしました。
対応方針
- 危険な脆弱性は迅速に対応して0を維持する
- 週間レポートで脆弱性が発生したら普段使っているITS（課題管理システム）でチケット化して対応する
- MinorやDelayedについては把握はしておき、いつ対処するかは状況によりけりということにする
- 判断できる基準を設けてワークフローを策定し作業をルーチン化する
ということにしました。
ざっくり言うと、赤タグ（Immediate）は逐次対応して即時リリースしていくという方針です。基本的には遅くとも1週間ごとに対応が回っていきます。
yamoryで自動スキャン・作業をワークフロー化することにより、着手予定の実装・運用系タスクやスプリント目標に影響せず、リソースも集中してリズムよく取り組めています。
以下のワークフローが、今回決めて取り入れたバックエンドのJava/Springフレームワークモジュール向けのもので、この他にもフロントエンド向けのワークフローも作りました。
今回立てたワークフローと方針で暫く試してみると、想定していた運用ができ、うまく回っていきました。
手始めにプログラムモジュールに対して脆弱性のスキャンを適用しましたが、Dockerコンテナで運用しているシステムもあります。yamoryにはコンテナの脆弱性スキャン機能も用意されてされているということで、どうするかを検討しています。 コンテナイメージの共有スコープは極力狭めたいという考えがあり、コンテナのスキャンについてはyamoryで行うか、それともコンテナをホストしているクラウドベンダーが提供しているSaaS機能を使うかが焦点になっています。 簡単でしたが、１つ目の脆弱性管理の実践の紹介でした。
CIに簡単に組み込めて安心感を得ることができました
次に、２つ目の適用プロジェクトの事例です。
新規事業のスクラッチからの案件で、スピード感を高めてフィードバックループのサイクルを早めていくことはもちろんこと、機能開発もどんどん行っています。
まず、チームには脆弱性対応へのアイディアとしてyamory活用の提案を出し、採用を即決し、存在する全てのリポジトリのCI Hookにyamoryを追加しました。
設定後は、だいたい月曜日にメールで脆弱性検知の通知が届くので、通知に「気づいた人が対応する」という運用で始めてみました。
暫く運用してみると、yamoryを採用したいと言った人が率先して対応していく流れになり、気づけばいつも特定の人（採用を推進した人）ばかりが対応しているという状況が生まれてしまいました。
個人依存にはしたくないなと思っていたところ、定期的に立てているプロジェクト全体目標の中に「様々なことで個人依存を減らし自動化をすすめる」というモノがあり、チームで対応策を考えてみました。
検討した結果、「検出したらチケット管理システムに脆弱性検知チケットを起票し、チームリーダーが担当者を割り振る」という案が出て、それを実行してみることに決めました。
これで、誰かが率先して対応するという形ではなくなりましたが、誰もが脆弱性対応に貢献できるようになりました。
続いて、yamoryを導入して気づいたことや所感をお伝えしたいと思います。
お悩み発生
yamoryを導入してからは「あぁ、これアップグレードをしないと...」と気にかけなくても済むという安心感を得ることができ、開発リソースも少なく済むという時間を得られた反面、導入した副作用のような悩みも発生しました。
それは何かというと、サービスの課金体系とプロジェクトのモジュール管理体系との兼ね合いです。
本案件ではイベントドリブンでデータを処理するバリエーションが多く、Serverless Functionのモジュールをたくさん用意しています。バリエーションが多い分、コードリポジトリをたくさん作っていたのです。
yamoryは契約毎に「合計スキャンアセット数の上限」が決められており、超えてしまうと追加でパック購入する必要が出てきてしまうそうで、もしかしたら「他プロジェクトや予算を圧迫してしまっているのではないか」という懸念に気づきました。
リポジトリの分け方は、開発スタイルやアーキテクチャ設計や運用設計にも影響してきます。yamoryで契約している数を超えないように、「節約のために本来しなくてもいいモジュールをまとめたり、リポジトリの数を節約しようかな」という意識がでてきます。
他にも、お金とリソースの配慮面でステークホルダーが増えて別視点で配慮する必要が増えました。
幸いなことに、まだ全社のプロジェクトを合わせても上限数には達していないということなので、リポジトリ数（スキャンアセット数）の精査や対応はしていませんが、yamory導入プロジェクトが増えてきたスキャンアセット数割当やプロジェクト毎に利用量に応じたコスト計算や利用料徴収などをしていくことになるのかなという将来をイメージしました。
さらにデータパターンなども増えてくる可能性もあるので、もしかしたら私達のプロジェクトはyamoryの料金形態と相性が悪いかもしれないのかなと。
料金によってSaaSやクラウドサービスを選択したりアーキテクチャを設計するように、yamoryもSaaSと考えれば、料金形態と案件特性との相性で取捨選択をしていき、設計や運用のし易さを加味して、トレードオフすることになりそうです。
ちょっとしたツラミ
もう一点気になったことが、依存ライブラリが内部で使っているライブラリに脆弱性が発見された時の事象です。緊急性が高くないMinorな脆弱性だとyamoryのトリアージで「今は対応しない」としてマークし、検知情報を消し込むのですが、暫く経つと同じ脆弱性がスキャンすることで検知されてしまい、「またこのライブラリが...」となって、警告に対して億劫になってしまいました。
感想をまとめると
悩みは発生したものの基本的にはyamoryを導入してよかったです。 想定していた課題感が別に出たのも興味深かったです。
その他には以下のようなことを感じました。
- 安心感を含め心理的な影響は多大だなと実感した
- 脆弱性検知ツールに頼るということは違うプロジェクトでも活用できそう
- 導入の敷居の壁は料金次第で技術要素としては問題なくフィットする
- 脆弱性検知ツールの仕様有無に関わらずセキュリティ情報はベストエフォートでキャッチするし情報交換するということはしたい
- 安心できるから何もしないということにはならなかった
- 世の情報を全部把握するということを課さなければ負荷に感じない
- もしかしたら情報収集は一種のライフワークかもしれない
まとめ
今回は2つのプロジェクトで実践した結果のご紹介をしました。 CIに組み込みやすいということで、導入しようと実践したプロジェクトではすんなりと設定・運用までもっていくことができたようです。新たな気づきもありました。
いくら脆弱性対応をしても何かが便利になるというわけではありませんが、安全にシステム運用してユーザさんにも安心してサービスを使い続けて頂くには必要なことですので、これからも目に見えない持続的な価値提供をできように取り組みを拡げていきたいと思います。