yamoryの今までを振り返り、2020年に目指すこと
はじめに
はじめまして。脆弱性自動管理ツール「yamory」の起案からサービス全体のディレクションに携わっているサイバーセキュリティ事業部 プロダクト開発部 部長の鈴木康弘（やっぴー）です。
2019年も終わりに差し掛かり、2020年が始まろうとしているので、このタイミングで「yamory」のこれまでを振り返りながら、今後目指していきたい世界や2020年の抱負について、言葉にしていきたいと思います。
脆弱性自動管理ツール「yamory」とは
脆弱性自動管理サービス「yamory」は大多数のソフトウェア開発で利用されているソフトウェア/サービス内のオープンソースソフトウェア（OSS）の脆弱性をソースコードを転送することなく管理し、対応優先度ごとに自動判別できるツールです。
ソフトウェア/サービス開発にて効率の面からも利便性の面からも当たり前になっているOSS利用。
開発が拡張していくと、「どこで、どんなOSSのどのバージョンが動いており、どの脆弱性に対応するか」を日々把握するだけでも一苦労になります。「yamory」はトリアージ（優先順位付け）作業も含めて脆弱性管理を自動化することで、脆弱性管理の工数を削減、ただでさえ不足が叫ばれるエンジニアの負荷を減らし、安心して、高い生産性で開発ができる世界を目指します。
特徴
- 直感的にソフトウェア/サービス内に含まれるOSSの脆弱性の全体像が把握できる全体ダッシュボード&UI
- 優先して対応すべき危険な脆弱性を自動判別し、対応コストを大幅削減するオートトリアージ機能
- インストール不要、すぐに利用できるSaaS型
なぜ「yamory」を開発しようと思ったか？
ビズリーチの初期社員から管理職に
2010年9月、当時ビズリーチはマンションの１室でやっている超スタートアップフェーズで、私は、そこに8番目の社員、3番目のエンジニアとしてジョインしました。
初期のビズリーチのプロダクト開発や、複数の新規事業の立ち上げプロジェクトをプロダクトサイドでリードする立場として多くのチャレンジをさせていただきました。
当時のビズリーチはとにかく事業が急拡大していたので、常に全職種を全力採用し続けており、（今も同じですね）エンジニアやプロダクトに関わる組織も次第に大きくなっていきました。その中で、私自身もマネージャーや開発部長といったような、管理職的なポジションを徐々に担当するようになっていきました。
管理職時代、セキュリティ問題に直面
私が管理職になったのと同タイミング（確か2016年頃）で、ビズリーチのTVCMも始まり、急速に会社の知名度が上がりました。それに伴い、セキュリティにおいて、ログ上から確認できるような攻撃が増えていったように記憶しています。
もちろん、会社としてあらゆるセキュリティ対策を進めていたのですが、その過程の中で、とても労力やコストがかかったりするなどのちの「yamory」事業の根本となるいくつかの印象的な出来事が起こりました。
これらの原体験を経て生まれてきた考えは以下のようなものでした。
「ソフトウェアプロダクト開発の中に、セキュリティリスク管理のプロセスを上手く楽に入れられないか？
要は、開発スピードは落とさず、脇を締めながら開発はできないか？」
今でいう「DevSecOps」という言葉になるのでしょうか。とにかくそういうことを考えるようになったのです。
ただ、当時の私はぼんやりとしたアイディアはあっても、何をするべきかはよくわかっていませんでした。
そのため、外部の大きな企業の開発部長やCTOレベルの人、セキュリティ担当者に自身の課題意識についてヒアリンングを重ねました。おそらく30社程度にはヒアリングしたと思います。
そこで分かってきたこととしては、しっかりとセキュリティ対策を進めている企業は、おおよそ共通して以下のようなことに取り組んでいるようでした。
- 外側からの脆弱性診断（アプリ寄りの診断）やPF診断（インフラ/NWやMWレイヤよりの診断）の定期的実施
- 手動や自動化を組み合わせながら定期チェックできる体制にしている
また、同時に以下の様な課題が存在することも把握できました。
- 脆弱性に対応するには、上記とは別にプロダクトの内側で利用されているコンポーネント（ソフトウェアの部品、主にオープンソースソフトウェア（OSS））を把握し、脆弱性をきっちり管理する必要がある（大多数のソフトウェア/サービス開発では効率性/コスト対策の面から、OSSを利用することが当たり前になっている）
- OSSの脆弱性情報は日々更新されるため、「どこで、どんなOSSのどのバージョンが動いており、どの脆弱性に対応するか」を日々把握するだけでも一苦労になる。
- このOSSの脆弱性管理を手動でやろうとするとスプレッドシート地獄に陥り、莫大な工数やコストがかかる。
- 何社か、スプレッドシート管理でやろうとして破綻した具体的なエピソードも聞くことができた
- また、様々なシステムレイヤーで脆弱性を管理するツールが別れており、レイヤーごとにツールを導入する必要が生じるため、統合的に管理することがとても難しい領域であることも理解できた
- 複数のツールを使っていると、ツールの管理そのものが煩雑になり、攻撃される危険性が高い脆弱性、つまり本質的に対応優先順位の高いリスクがわからなくなる
- この脆弱性診断に時間を奪われることによって、本当にエンジニアが注力したい開発の時間が奪われている可能性がある
※もちろん、もっと様々な対策はやっていかなければいけませんが、今回の記事のテーマに合わせて抜粋しています。
課題意識から事業化へ
ビズリーチでの脆弱性診断やPF診断に関しては、全社のセキュリティ部門ができ、外注や一部内製化もしながら、定期実行できる体制になりました。
そこで、私は先述の出来事から得られた課題感から以下のようなアイディアを具体的に実現したいと思うようになりました。
- プロダクトの内側で使われているコンポーネント（ソフトウェアの部品、OSS）に関して、脆弱性を管理できるツールを作りたい
- そこから様々な脆弱性管理ができるツールに発展させ、プロダクトの脆弱性を統合的に管理できるツールを作りたい
- 最終的には、エンジニア（セキュリティ部門や開発部門）が楽に連携しながら運用が周り、安心して前を向いて開発ができる仕組みを作っていきたい
そこで、他社企業の方々とのヒアリングで得た上記のようなニーズを生かし、New
Bamboo!というビズリーチの新規事業立案制度を利用し、事業化が決定しました。
後に「yamory」と名前がつくアイディアの事業化が現実のものとなった瞬間でした。
この辺りの出来事は、会社ブログであるこちらの記事にも詳しくのっているので、こちらもぜひ御覧ください。
https://reachone.bizreach.co.jp/entry/2019/09/27/180245
「yamory」は2019年8月のリリースまで、そしてリリース後で何をしてきたのか？
スーパーサイヤ人級のエンジニアを5人採用
2018年1月。プロダクト開発の現場でおきているセキュリティ課題を総合的に解決するツールを目指して、社内新規事業プロジェクトがスタートしました。
スタートしたといっても初めの頃は、鈴木の1人チームでした。
社長室に配属され、プロトタイプ作成や技術研究と仲間探し（採用）の毎日。
この「yamory」は開発の難易度が高いプロダクトになることが予見されてました。
そのため高い技術力を持っているスペシャリストタイプのエンジニアにチームに加わってもらう必要があったのです。
当時は1日のほぼすべての時間を採用にあてていました。そして残った時間で事業計画や開発技術の調査を進めました。
その間、採用や調査を通して、おそらく数百人（1日3人会うペースを半年ぐらい）のエンジニアやセキュリティエンジニアの方々にお会いしたでしょう。
お会いしてくれる人に構想をぶつけ、共感してくれる人や採用は厳しいけど使いたいと言ってくれる人もいれば、真っ向から否定してくる人たちもいて、そんな人たちと会う毎日を過ごしていました。
しかし、この数百人と合った経験が意外にも事業とプロダクトにプラスに働きました。
また、数百人に事業やプロダクトの説明をすると、回数を重ねるごとに自然に研磨され、事業コンセプトもシャープになりました。
さらに、この事業とプロダクトにニーズがあると言ってくれる人達も多くいたため、事業を推進していく自信にも繋がりました。
そして何より、結果的にスーパーサイヤ人級のスペシャルなエンジニアが5人チームに加わってくれることになりました。
社内ドッグフーディングでプロトタイピング
また、エンジニアの採用と同時並行でプロトタイプ開発にも没頭しておりました。
動くものが出来たらすぐに社内のエンジニアやセキュリティチームの方々に披露し、あーでもない、こーでもないとフィードバックをいただきながら、ビズリーチ内で運用を開始しました。
ビズリーチの文化には社内で徹底的にドックフーディングするというものがあります。
さらに社内の皆さんのめちゃくちゃに協力的な文化土壌もあり、プロトタイプがすごい勢いでどんどん形になっていきました。
おそらく社内で6周ぐらいはプロダクトをガラッと変えながらプロトタイピングしたと記憶しています。
このドッグフーディングにより、プロダクトに対する様々な有益なフィードバックやアイディアを頂きました。
その中の一つが「細かい脆弱性まで多く出るので本質的にリスクが高い脆弱性がわからない、わかりにくい」といったフィードバックでした。
ここから攻撃コード、PoCによる悪用可能性判断と、それによる優先順位付けするという、現在につながる製品コンセプトが出来上がりました。
この製品コンセプトがプロダクトに実装できた頃、この製品を社外の人達に試してもらいたいと思うようになりました。
クローズドβ版の開発と社外検証協力企業への営業活動
2018年の後半からプロトタイプではなく、社外検証を実施するため、社外向けのプロダクト開発と営業活動をスタートさせました。 営業活動の初期には、コンセプトやプロトタイプを見せ、クローズドβ版の製品で検証してもらえる企業様を探しました。とにかく限られたツテを辿ってひたすら営業しました。
しかしながら、ビズリーチで実施したたくさんのドッグフーディングの実績がここで活きました。
この実績を含めて提案することができたため、提案に説得力を出す事ができ、社外検証に参画してくれる企業様が出てきました。
結果として数十社の企業様に社外検証のご協力をいただくことができました。
この社外検証の中で多くのフィードバックをいただくことができ、この貴重なご意見が当時のプロダクトのリリース、また現在も続くプロダクト開発に繋がっています。
当時、検証にご協力いただいた企業の方々には本当に感謝の念しかありません。本当にありがとうございました。
そして「yamory」リリースへ
2019年8月、ビズリーチのPRチームやデザインチーム、法務に協力を仰ぎ、PRの戦略策定や製品ページ、規約策定などがスピーディーに行われ、「yamory」は2019年8月27日にリリースされました。
PRチームのご協力のおかげで、リリース時には30以上のメディアに取り上げられ、多くの反響を呼びました。
そして現在「yamory」はリリースから数ヶ月にも関わらずありがたいことに多数のお客様に導入いただいております。
そしてチームは実際のお客様にご利用いただき、お客様の声を丁寧に集め、本質的なプロダクトの課題を洗い出し、機能追加やUX改善を積み重ねていく、そういう日々を過ごしています。
「yamory」の今後と、2020年の抱負
チームのみんなと決めたミッション、ビジョン
「yamory」チームはプロダクト開発と事業化の過程で徐々にチームメンバーが増えていきました。
そして10人を超えたあたりで、合宿やチーム分けなど多様な試みを実施することができるようになりました。
このような試みの中で、集まったチームメンバーの想いを形にすべく、ミッションとビジョンをみんなで決めました。
「yamory」のミッション/ビジョンは以下となっています。
ミッション：安心してテクノロジーを活用できる世界を実現する
ビジョン：すべてのエンジニアにとって、セキュリティを当たり前にする
このミッション/ビジョンは次のような考えから導き出されています。
- 「yamory」はそもそも鈴木の原体験である「ソフトウェアプロダクト開発の中に、セキュリティプロセスを上手く入れたい、その結果、不安に頭を抱えることなく、エンジニアが本来集中すべき開発を安心してできるようにしたい。」という発想から始まった。
- また、今後の世界はDXが進み、今までインターネットに繋がっていなかった、金融や物理サービス（自動運転や、ロボディクスによるサービス）がどんどんインターネットに繋がり、ソフトウェアでサービス提供されるものがどんどん出てくると思われる。
- そうなればサイバー攻撃に影響はますます拡大し、今までよりも大きなリスク、具体的には人命に関わるようなリスクが顕在化し、より大きなリスクになる。
- それらを防ぐためにもソフトウェア/プロダクト開発の段階でセキュリティリスクを管理するプロセスを正しく組み込み、管理していくことはますます重要になる。
- 人類が今後より安心安全に、様々なテクノロジーを活用していくためには、ソフトウェアプロダクト開発のセキュリティチェックやプロセスを、エンジニア が当然当たり前のようにやれるようにならないといけない。
- それをリードし、支援していくのがyamoryの使命
というところに落ち着き、このようなミッションビジョンになりました。
yamoryが描く大きな夢
我々「yamory」チームはとてつもなく大きな夢を描いています。
大きな夢はありながらも、まず、ソフトウェアのコンポーネント（OSS）のリスク管理を正しくやれるようにしてよう、そこからやっていこうということで、今は、ミッション、ビジョンをこのように理解してやっています。
ミッション：安心してテクノロジー（まずはOSS）を活用できる世界を実現する
ビジョン：すべてのエンジニアにとって、セキュリティ（まずはOSS脆弱性管理）を当たり前にする
今後数年はこの目標の実現に向けてひたむきにやっていきたいと考えています。
yamory に対して頂いているご要望
- C#やGo言語に対応してほしい
- ライセンスのリスク管理もしたい
- パッケージ管理できていない古いシステムのOSSの方が心配、だから、チェック対象ソフトウェアを入力できるようにしてほしい
- MW/OSレイヤの脆弱性も気になる（今はアプリライブラリ/FWだけスキャンできる）
- SSOがほしい
来年（2020年）の挑戦
最終的にはすべて実現したいのですが、すべて一気にはできないので、優先順位をつけてしっかりと対応していきたいと考えています。
そのためにも、チーム全体でお客様をしっかり理解し、共感し、お客様の方向をきちんと向いてプロダクトの改善を積み重ねていける、そういうチームをメンバーみんなとつくっていきたいです。
ビズリーチ社のクレドで、「お客様の感動にコミットしよう」という言葉がありますが、お客様の期待を超え、感動を与えられるぐらいの、サービス、プロダクト、そういうことを実現できるチームにしていきたいです。
これは今のチームができていないということではなく、今後どんどんチームの人数も増えていくフェーズを迎えます。
どんどん人数が増えていっても、当然のように顧客を向いたサービス改善、開発ができるそうことをしっかりやっていける組織やチームにしていきたいという意味です。
あとは、MW/OSレイヤーに関する研究をスタートしたい。
今は、アプリケーションのライブラリやFWのレイヤーが「yamory」の管理対象となっています。
これをMW/OSレイヤーも統合管理ができるようにし、OSSのセキュリティはまず「yamory」に任せておけば良いよねというプロダクトにしていければと考えています。
2020年は「yamory」にとって挑戦の年です。
お客様と向き合いながらしっかりと現在のサービスの品質を高め、同時に今後に向けた新たな基盤づくりを実現できる一年にしていければと想います。
みなさま応援のほどよろしくお願いいたします。
お知らせ
脆弱性自動管理ツール「yamory」サービスサイト
以下のプランが利用可能です。
- 個人向けフリープラン
- プロプラン無料トライアル（30日限定）
「yamory」を一緒に盛り上げていく仲間を探しています
yamoryでは、yamoryのミッションやビジョンに共感し、一緒に「yamory」を盛り上げていく仲間を探しています。ご興味ある方はぜひ下記のリンクよりお気軽にご応募ください。
- 経験豊富なScalaエンジニア
- エンジニアリングマネージャー
- SaaSプロダクトのセールス、CSやマーケティング経験豊富な責任者
https://hrmos.co/pages/hrmos/jobs/3100100100498
Twitterアカウント
「yamory」公式Twitterアカウントを運営しています。
ソフトウェアプロダクトのセキュリティ、脆弱性情報やDevSecOps、セキュア開発情報を発信しています。ぜひフォローよろしくお願いいたします。