株式会社TRUSTDOCK様

急拡大する組織の脆弱性管理を「標準化」 — yamoryで実現した組織全体のセキュリティレベルの底上げ

eKYC（オンライン本人確認）サービスの累計導入社数No.1（※）を誇る株式会社TRUSTDOCK。社会インフラとしての責任あるサービスを提供する同社において、セキュリティ対策は事業の根幹を成す重要課題です。 開発エンジニアが主体的に行っていた脆弱性対策を、組織拡大に合わせていかにして「全社的な標準運用」へと実現させたのか。情報セキュリティ部 部長の五島 宙也氏に、yamory導入の経緯と、導入によって実現した持続可能なセキュリティ管理体制についてお話を伺いました。

※：2024年12月時点での、eKYCのコア機能を自社開発しているサービスにおける導入社数（東京商工リサーチ調べ）

課題

• ソースコード管理ツールの標準機能だけでは、OSやコンテナレベルの脆弱性情報の収集が不十分だった
• 組織が拡大する中で、特定のエンジニアの高いスキルや自主性に依存していた運用体制を、組織全体で標準化する必要があった
• OSSのライセンス管理やEOL（End of Life）管理を含めた、包括的な管理体制の構築が求められていた

• コンテナレベルの脆弱性スキャンが可能で、アプリケーションからインフラまで一元管理できる点
• 対応すべき脆弱性を自動で選別するオートトリアージ機能の精度の高さ
• 脆弱性だけでなく、EOLやOSSライセンスも一元管理できる点

導入後の効果

• メイン担当者による定期的なトリアージ運用を確立し、対応漏れを防ぐ体制を実現
• 情報セキュリティ部がチケットの起票から連絡までを行うことで、開発チームが修正作業に集中できる環境を構築
• リスクが可視化されたことで、ダッシュボード上の緊急度の高い脆弱性を常に低く抑えられた状態に維持

五島氏：
当社は、eKYC（オンライン本人確認）サービスとデジタルIDウォレットなどを提供している、本人確認の専門会社です。犯罪収益移転防止法をはじめとする各種法律に準拠した本人確認業務をAPIとして提供しており、金融機関からシェアリングエコノミーまで、幅広い事業者様にご利用いただいています。
私は情報セキュリティ部の部長として、全社的なセキュリティガバナンスの構築や運用、そしてプロダクトの安全性を担保するための技術的な対策を統括しています。
 

五島氏： 以前は、ソースコード管理ツールに標準搭載されている依存関係スキャン機能を利用して脆弱性をチェックしていました。しかし、ライブラリレベルのスキャンはできても、OSレベルやコンテナレベルの脆弱性までは十分にカバーできていないという課題がありました。
また、当時の運用体制についても、組織拡大を見据えた「標準化」が必要なフェーズにありました。 もともと弊社のエンジニアはセキュリティ意識が高く、自主的に自動アップデートの仕組みを取り入れたり、定期的なメンテナンスを行ったりしていましたので、大きなインシデントに繋がるような問題は起きていませんでした。 

しかし、組織が急拡大していく中で、こうした「個人の高い意識やスキル」に依存した体制を維持し続けるのは難しくなります。エンジニアが主体的に行ってきた素晴らしい文化を、組織全体に広げ、誰が担当しても一定の品質で運用できる「標準化された体制」を構築することが必要となっていました。
 

五島氏：
1つ目は、我々の技術環境において必須となる「OSレベルおよびコンテナレベルの脆弱性情報」を収集できる点です。 これまで利用していたソースコード管理ツールなどは、アプリケーションライブラリの依存関係はスキャンできても、その下層にあるOSやコンテナイメージ自体の脆弱性までは十分にカバーできていませんでした。当社ではコンテナ技術を積極的に採用しているため、アプリケーションだけでなく、インフラ層であるOSやミドルウェア、コンテナまで深掘りして一元的にスキャンできる機能は、ツール選定において必須条件でした。
 

yamoryの対応範囲と提供価値
 

2つ目は、脆弱性だけでなく「EOL（End of Life）」や「OSSライセンス」の管理が可能である点です。 セキュリティ対策と同様に、利用しているOSSのライセンス違反がないか、サポート切れ（EOL）のソフトウェアを使っていないかといったコンプライアンス面の管理も重要です。

しかし、膨大な数のライブラリ情報を手動で収集し、台帳として管理するのは現実的ではありません。yamoryはこれらをスキャンと同時に自動でリスト化し、包括的に管理できるため、我々が目指していた「管理コストを下げつつガバナンスを効かせる」という目的に非常に合致していました。
 

EOL機能
 

そして3つ目が、「オートトリアージ機能」です。 日々検知される膨大な脆弱性情報のすべてに対応しようとすれば、開発現場はパンクしてしまいます。
yamoryのオートトリアージは、単にCVSSスコア（深刻度）だけで判断するのではなく、「攻撃コードの有無」や「外部からの攻撃可能性」といった実質的なリスク要因を組み合わせて、対応優先度を自動判定してくれます。

論理的かつ効率的に「今すぐやるべきもの」と「直ちには対応が不要なもの」を選別できる点は、運用の効率化において非常に重要だと判断しました。
 

オートトリアージ機能
 

五島氏： 現在は、情報セキュリティ部が主導権を持って運用フローをコントロールしています。 具体的には、定期的にトリアージ画面を確認するというルーチンを組んでいます。

yamoryが自動で検知・優先順位付けした脆弱性について、担当者が内容を確認し、対応が必要なものについては社内のチケット管理システムでチケットを起票します。そこから各開発チームのメンションをつけて「この脆弱性の対応をお願いします」と連絡を入れる、というフローを徹底しています。
 

五島氏：
そうですね。yamoryは組織横断的に脆弱性を検知できる点が優れていますが、一方で、どのリポジトリのどの資産で発生しているかといった詳細を特定するには、ある程度の調査が必要な場合もあります。これらをそのまま現場に投げると、「誰がいつ対応するのか」が曖昧になったり、調査工数がかさんだりしてしまいます。
そこで、開発チームでの主体的なアップデート活動は継続してもらいつつ、情報セキュリティ部側で「本当に優先度が高く、エスカレーションすべきもの」を選別することにしました。これにより、エンジニアは不要なノイズに惑わされず、本来注力すべき開発業務に集中できる環境を整備できたと考えています。

また、yamoryのオートトリアージ機能が優秀なので、我々が判断する際も「攻撃コードが出ているから最優先」「これは外部公開していないから様子見」といった判断がスムーズに行えています。
 

五島氏：
非常に大きな変化がありました。具体的な修正依頼が飛んでくることで、開発者自身が脆弱性をより「自分ごと」として捉えるようになり、迅速に対応してくれるようになりました。

その結果、ダッシュボード上の脆弱性件数は、現在は常に件数を低く抑え、管理可能な状態を維持できています。SREチームなども自発的に状況を見てくれるようになり、可視化によって組織全体のセキュリティ意識が底上げされたと感じています。
 

五島氏：
まずは現在の運用を継続し、脆弱性の件数を適切に低く抑えられている状態を維持していくことが第一です。
また、yamoryによって脆弱性管理が効率化されたことで、私たちはより本質的なセキュリティ対策や、事業成長に直結する開発業務にリソースを集中できるようになりました。
今後は、この「標準化された運用」をさらに強固なものにし、組織規模がさらに大きくなっても、スピード感を損なわずに高いセキュリティレベルを維持し続けていきたいです。
 

五島氏：
脆弱性管理において、すべての脆弱性に手動で対応しようとすると、どうしても現場は疲弊してしまいます。yamoryのように、リスクを自動でトリアージし、可視化してくれるツールを導入することは、運用工数を削減するだけでなく、エンジニアが本来注力すべき開発業務に集中できる環境を作ることにも繋がります。 組織としてのセキュリティ運用の標準化を目指す企業にとって、yamoryは非常に強力な武器になると思います。