アットウェアではシステム開発・運用業務をしていく中で、様々なツールやサービスを導入しています。
ここ数年かけてセキュリティ周りへのアプローチとして、脆弱性管理サービス「yamory」を新たに導入しましたので、どういう視点と取り組みで組織に浸透させていったかを紹介したいと思います。
本記事では2年かけてやった社内への導入編として紹介し、次の記事では実際にプロジェクトで適用した実践編をお届けします。
システム開発をやっていく中で持っていた課題感
システム開発をやっていると、設計手法・実装フレームワーク・マネージメントなど様々な分野でナレッジを活かしてゴールに向かっていくわけですが、ゴールというのは納品を指すのではなく、ファーストリリースも通過して、永続的に価値を発揮し続けられるシステムとチームを形成していくことにあります。
その中で運用という面で避けて通れないのが、セキュリティ対策です。
クラウドパタンのベストプラクティスや最新のライブラリを適用したとしても、時間の経過と共に脆弱性が発見されることは避けて通れません。
システムの多くはMavenやGradleなどで依存関係のライブラリを管理しており、記憶で覚えきれなくなるほどの数になります。
そういう中で、ライブラリのバージョンは機能追加により不定期でアップデートすることもあれば、重大な脆弱性が発見されたタイミングで上げることがあります。
重大な脆弱性が見つかったライブラリ以外についても、「影響度が少ないだろう」とバージョンアップを放置しておくと以下の2つの観点で問題になることが多いので、小まめにアップデートをしていくという方針を取っているプロジェクトチームが多いです。
- セキュリティホールが重なっているライブラリが依存関係を拡大させビックバンアップデートとなってしまう
- バージョンが古いライブラリは最新のバージョン（バージョン2つ飛ばしなど）にアップグレードできないことがある
- リファクタリングの粋を超えどんどん手がつけにくくなる
- アップデート作業にかける専用予算などを確保して工数の問題が発生しがち
次に、プロジェクト横断に関連する状況をご説明します。
弊社では利用している主要なフレームワークはありますが、プロジェクトチームによって最適なモノを選んでいるため、専任者として全プロジェクトの利用ライブラリを把握してアップデート計画を立て、対応していくという体制をとっていくのはコミュニケーションコストを含め現実的ではありません。
そうなると個別最適となり、各チームで（もしくは中の誰かが）公開されているCVEやIT情報記事をRSSで購読したり、SNSでキャッチした情報でチームごとに対応しています。チームごととはいっても、少しでも効率化や情報共有をしてお互いに助け合っていこうということで、技術・セキュリティを扱う社内チャットへ展開しナレッジ共有を図っていこうという取り組みを長年行ってきました。
しかしながら、全ての脆弱性を自発的（プル方式）に調べていると、作業の重複や抜け漏れが発生する可能性がありますし、人的リソースの使い方がベストエフォートな対応となり最適なリソース配分や時間の使い方ではない状態でした。
最近ではAmazon InspectorやGitHub Dependabotが出てきて、検知する仕組みを利用し、社内横断でナレッジを溜めたり、取り組みがしたいと考えていたところでした。
yamoryとの出会いと紹介
そういった課題感を持っている状況でyamoryというサービスが世に登場して、yamoryのプロダクトオーナーが弊社に以下のような問い合わせをしてくださいました。
「新規事業としてサイバーセキュリティソリューション「yamory」を立ち上げました。
サービスの品質向上に向けて、様々な企業様からお話をお伺いしたく考えております。
「yamory」のサービスについて電話・web会議・面談等でご意見をお伺いできますでしょうか。
これはいい機会だと思い、Webミーティングを開いてお話を聞かせていただくと、以下の機能があることがわかりました。
- SaaSでサービスを提供しているがソースコードを預ける必要がない
- 預ける情報は依存関係を示すpom.xmlなどのメタ情報だけでよい
- ソースコードの管理を最小スコープのまま維持できる
- 使っているライブラリの脆弱性をリアルタイム（日次やCIと連動）で検出できる
- 攻撃方法や脆弱性の種類などレポート形式で表示
- 危険性を段階わけして一覧化・対応するかどうかのステータス管理（トリアージ）ができる
- 社内の複数チームで利用できる組織機能があり横断した脆弱性状況も把握できる
私達の課題感を解消してくれるツールになりえると感じ、またサービスが開始されて間もないということで、フィードバック＆トライアルに参加させていただくことになりました。
会話の中では「こういう事ができたらいいな」という事を開発者とプロダクトオーナーの方と直接会話でディスカッションしながらニーズを伝えることができ、また自分たちのこともより明確に理解できて、いい場となりました。
社内への導入に向けて
何はともあれ実際に使ってみようということで、イメージしていた通りの検知の仕組みで、可視化とハンドリングのサイクルを回していけることがトライアル期間の利用の中でわかりました。
CIへの組み込みにあたっては特別なagentをインストールする必要がなく、「APIのエンドポイントにAPIキーをcurlコマンドで送信すればよい」というシンプルな仕組みで、導入の敷居がとても低かったです。
弊社が主に使っている言語サポートとしては、JVM上で動作するJavaやScalaを始めとする（mavenやgradleやsbt）とJava Script（npm）に対応しており実用に足る状態でした。ただ、トライアル時点ではPythonのpip対応の要望はあるがまだリリースできていないとのことでしたが、対応していく方向性ではあるということでしたので、カバー範囲として充分でした。
いくつかの商用サービスを開発しているプロジェクトチームに評価を協力してもらって、社内の幾つかのリポジトリにも適用してみました。
社内でのファーストインプレッション
全社的に最初の評価をして出たフィードバックは意外な反応でした。
それは「サービスのポテンシャルは高いものの、自分たちのチームがこのサービスを活かし切れる状況ではない」という意見が複数のチームからでたことです。
例えば、SIの案件としてプロジェクトチームが今までセキュリティ対策に対して取っていたアプローチや、顧客と共にマイルストーンを決めて保守開発をしているやり方、プロジェクトによってはファーストリリース前という段階というケースもありました。脆弱性対策は大事だということはわかっているが、シードステージで予算の比重のかけ方のバランスどりに影響するといった点です。
これは私達のフィッティングの問題で、話をよくよく聞いてみると「とはいったものの、ぜひ使ってみたい」という意見がほとんどでした。
いきなり全振りで今までのやり方を考慮せず切り替えるのではなく、ホップ・ステップ・ジャンプ（ふつうのことにしていく）が必要だなと感じて、いつでも辞めれる・強制はしない・関心を高める、といった、推進活動をベースにして導入戦略を立てていくことにしました。
初年度の導入指針
初年度はまずホップをしたいということで、以下の導入コンセプトを立てて行き渡らせることに注力しました。
自分たちが認識していない脆弱性や未来に発生しうる脆弱性にも対応できるように、
アットウェアとして「システム開発をする時にはこれくらいのことはやっているよ」
というレベルの底上げをしていきたい。
社内で年一回行っている全社セキュリティオリエンテーションでも、ひとつのテーマとして話題に触れ、あるべき論を押し付けないということも心がけて、以下のような導入指針をきめて普及を進めました。
- チーム毎にどのアプリケーションをスキャン対象にするかなどはお任せします
- すぐ絶対に脆弱性0にする必要はなく誰かに報告を義務付けるということはしません
- 使いたいという人があればいつでも招待します
契約を結ぶ
トライアル期間の終了に際し、社内からの理解も得てこの取組をさらに推進していくことを決めて、それなりの金額で年間契約を結びました。（専任者を設けるよりは全然安い金額ですが）
契約に至るまでにyamoryの中の方と交流させていただいた中での印象も導入の意志決定に影響したので、幾つか紹介します。
- 開発者やプロダクトオーナーと直接やりとりでプロダクトの方向性がイメージができた
- マイルストーンとその意義を聞いた時にパワーをかけ方・優先度の付け方に共感した（将来性）
- 「社内へ普及しSIという業態で適用する」という弊社の課題感を共有した時のディスカッションで会話のコンテキストレベルが合った
- 社内への勉強会やデモなど協力を惜しまない姿勢
- 不安に感じた点について問い合わせたところ真摯な対応で説明いただけた
- ユーザの意見を大事にしつつプロダクトのビジョンと方向性がしっかりしていた
1年経って普及はできたのか？
できませんでした。
と書いてしまうと誤解を生んでしまうかもしれませんが、yamoryという言葉をちらほらと会話の中で聞くようになったり、社員が四半期ごとに立てている個人目標の中に「yamoryを導入する」と書いてくださる方がでてきました。
非機能要件にあたる脆弱性管理を他の要件と共にバランスよくやっていきたいという意識が導入する前より顕著に高くなってきており、取り組みが作用してくる機運が高くなってきたというのを感じました。
半年後にヒアリングを行った結果、各プロジェクト事情を聞かせてくれました。
わかったことは、「本格導入はまだまだ道半ば」ということです。
そこで、1年目の契約が終わるタイミングくらいにyamoryの開発者とプロダクトオーナーと営業さんにご相談して、社内勉強会を開催していただくことにしました。
勉強会の後半部分で実際にPoCコードが存在する脆弱性を再現してみましょうということで、デモをしていただきました。この勉強会には多数の方が参加して事後アンケートでも非常に反応がよかったです。
「こういうこと大事だよね」という意見や「また勉強会をやって欲しい」という意見をもらいました。
1年目はホップの年と位置づけたので、次の年は更にステップアップしていくにはどうしたらいいかを考えました。
2年目の契約に向けて
今までは私が中心になって推進して私が最終的に判断の意志決定をしていました。
これからさらに飛躍するために、個人ではなく組織としての取り組みに発展したくて、
その輪を拡げてみようということを意識しました。
その時に、yamoryの契約に向けて営業さん・プロダクトオーナーとディスカッションしている時に伝えたのは「社内で一人も継続して使いたいという人がいなければ契約を更新しません」という意志決定の基準です。
つまり、自分のチームや全社で契約金額のコストをペイできるかどうかはさておき、
「もし、どこかのプロジェクトの案件で引き続きプロジェクト予算を使ってでも活用していきたいのであれば継続方向で調整をしていきますが、使い続けたいという声がなければ一旦契約は満了する方向にします。」
ということを全社展開したところ、使ってもらっていたプロジェクトメンバーからの反応は「継続できるなら利用したい」という声がいくつも届きました。
この瞬間に、今まで「各プロジェクトに使ってもらっていた」という状態から「自分の意志で使っている」にステップアップできたのです。
これで、2年目の契約に向けての機運もあがり、後押しをもらいながら期日ギリギリになってしまいましたが、yamoryの初めての契約更新ができました。
2年目でついに実運用で活用が確立
yamoryはサービスとして成長し、ホストスキャンの機能も加わりさらに便利になりました。
Docker対応やライセンス管理機能なども発表され実用性がどんどんあがってきました。
そんな中、CIへの組み込みやITSでのチケット管理フローまで確立できたチームがついに現れました。それに加えて、新規に立ち上がったプロジェクトでも導入されました。
log4j2の脆弱性が世の中を賑わせたりして、脆弱性という話題が賑わった年でした。
yamoryの活用事例のインタビューが他社で発表されたりして、HPに掲載されている導入企業数も増えたようで、弊社取引先も導入していたりして、世の中の需要の実感を感じました。
社内でも実用的な活用ができはじめて、取り組みが実になってきました。
そして3年目の今
こうやって、やったことや感じたことをアウトプットしようという段階まできました。
「世に同様のツールが充実してきてどれを選べばいいのか」という悩みの種も増えましたが、根本的な課題へのアプローチや意識を忘れず、この取り組みを通して文化形成の礎もできた気がします。
どんないいものでも、運用段階に持っていきDevOpsとして融合していくまでが大事で、小さな積み重ねが糧になっていきます。これからもよいサービスやツールがあれば実体験を通して評価し、導入を検討して、よりよいシステム開発ができる組織になっていければと思います。
