アシュアードについて

佐藤：アシュアードはビズリーチを祖業とするVisionalのグループ会社です。ビズリーチで培った事業づくりの知見を活かしながら、サイバーセキュリティの課題解決に挑戦している企業です。

事業としては大きく分けて2つのセキュリティサービスを展開しています。1つはSaaSや外部委託先といったサードパーティのセキュリティリスク管理を行うセキュリティの信用評価プラットフォーム「Assured」。そしてもう1つが、今日ご紹介する自社のシステムやソフトウェアの構成管理、脆弱性管理を行うための脆弱性管理クラウド「yamory」です。これらのサービスを展開しながら、企業様のセキュリティリスクへの対応を内外両面で支援させていただいております。

yamoryは、クラウド環境でもオンプレミス環境でも対応可能で、脆弱性管理からSBOM対応、さらにはクラウドセキュリティまでカバーできる国内唯一のサービスです。お客様が保有・開発・運用しているシステムの構成やSBOMといったソフトウェアの資産情報を自動で収集し、私たちが日々集めている脆弱性情報のデータベースと照合することで、システム内のリスクを検知するだけでなく、対応管理まで一元的に行えるプロダクトになります。

製造業のお客様を中心に、業界・規模を問わず様々な企業様にご利用いただいております。

Situation：攻撃、脅威トレンド

佐藤：まず現在の状況、攻撃や脅威トレンドについてみなさんに共有したいと思います。DXが進み、企業活動を支えるシステムが増え続けています。社会を構成するさまざまなサービスが世の中に広まってきている一方で、裏を返せばそれだけサイバー攻撃の対象、攻撃面が増え続けている状況にあります。

佐藤：具体的な事例を3つご紹介します。まず、四国や大阪の医療機関のケースです。2021年、2022年に、院内を構成するネットワーク機器、具体的にはVPNの脆弱性を悪用されて、そこを起点として院内ネットワークに侵入されました。結果として病院のネットワークが止まってしまい、復旧まで約2か月かかっています。

2つ目の事例は、自動車製造のサプライチェーンの話です。自動車メーカーの主要サプライヤー1社がマルウェアに感染した結果、工場のネットワークが止まってしまいました。一部の生産ラインが止まり、14工場の28ラインが停止するという事態になりました。

最後3つ目が、Log4jの問題です。オープンソースのパッケージとしてよく使われるApache Log4jに、ゼロデイ脆弱性、任意のコードがリモートで実行できるという脆弱性が発見されました。直接的に使われるパッケージだけでなく、間接的に使われるケースも非常に多かったので、どこで使われているのかが分からないという点で対応が難しかったのです。

少し前まではセキュリティインシデントというと情報漏洩が中心でしたが、今では社会インフラそのものが攻撃対象になっています。また、間接的に依存しているものも含めて、原因がどこにあるのか見えにくい事例が増えてきています。

IPAという団体が毎年発表している「情報セキュリティ10大脅威」の2025年版では、組織向けの脅威として、1位がランサムウェアによる被害、2位がサプライチェーンや委託先を狙った攻撃、3位がシステムの脆弱性を突いた攻撃という形になっています。特に注目したいのは、これらすべてが相互に関連しているという点です。

佐藤：特にランサムウェアに関しては、レポートを詳しく見ると、攻撃手口として脆弱性を悪用してネットワークから感染するというものが挙げられています。脆弱性対策を行わないままインターネット上に接続されている機器に対して脆弱性を悪用するという手口が非常に広がっているのです。

また、OWASP TOP10というWebアプリケーションのセキュリティリスクのランキングも4年に1度公開されています。2025年のリリース候補版が公開されており、4年前の2021年版で6番目に位置していた「脆弱で古いコンポーネント」というカテゴリーが、今回の版では「ソフトウェアサプライチェーンフェーラー」という形で整理されて、より上位にランクインしています。

佐藤：単一のソフトウェアだけでなく、その依存関係、ビルドシステム、デプロイのインフラストラクチャーまで含めて、この中で扱うようになっています。開発環境から本番環境までのすべてのプロダクトのライフサイクルに対して、サプライチェーンのセキュリティを意識していかなければいけない時代になっているということです。また、2番目にはセキュリティミスコンフィギュレーション、主にクラウド上のセキュリティ設定ミスも上位に挙がっています。

このように、脆弱性やサプライチェーンに関するリスクが年々高まっていることが、各種レポートからも明らかになっています。

Complication：なぜ対策が難しいのか

佐藤：なぜ対策が難しいのかという話をしたいと思います。主に3つ挙げています。1つ目が依存関係の複雑化、間接依存のパッケージやサプライチェーンの話です。2つ目が生成AIによる開発プロセスの変化。3つ目が組織の構造的な課題です。

SourceClearという団体の調査結果によると、ITシステムにおけるOSS構成要素は90%以上を占めています。自分たちで書くコード、AIで書かせるコード、いわゆるカスタムコードは全体の10%以下です。つまり、開発コードより多くのOSSコードに支えられることで、自分たちのシステムが動いているのです。

佐藤：yamoryの2024年のデータでは、検知された脆弱性のうち「Immediate」という最高レベルの危険度として位置づけている脆弱性の84%が、間接的に導入されているソフトウェアに対して見つかったものでした。間接的に利用しているソフトウェアの脆弱性によるリスクが大きいということです。間接依存まで含めて、正確に自分たちがどんなソフトウェアに依存しているかを管理することが必要になってきます。

脆弱性だけでなく、マルウェアやマリシャスパッケージと呼ばれる悪意のあるコードが直接的に組み込まれるケースも増えてきています。4つほど事例を挙げますと、まずXZ Utilsという広く使われるパッケージで、長期間にわたって信頼を獲得していたメンテナーのアカウントが、突然悪意のあるコードを含むようになったケースがありました。

次にDependency Confusion、依存関係かく乱という手法があります。企業がプライベートで内部的に使っているパッケージと同じ名前のパッケージを公開リポジトリに登録して、誤ってインストールさせることを狙った攻撃です。

また、タイポスクワッティングというものもあります。よく使われるパッケージ名に似た名前の悪意あるパッケージを登録しておき、人の打ち間違いを狙って悪意あるソフトウェアをインストールさせる攻撃手法です。さらに今年は、NPMの正規パッケージのメンテナーアカウントが乗っ取られ、もともと信頼されていたパッケージに悪意のあるコードが埋め込まれるケースもありました。

一見正常に見えるリポジトリやパッケージであっても、特定のバージョンだけが汚染されているケースが増えており、常に継続的なリスク管理が必要になっています。

佐藤：次にAI開発の影響です。AI開発の進展により、これらの課題をより把握することが難しくなってきています。

もともとAIが普及する前は、エンジニアがチームを作って、お互いにコードレビューをしながら1つのプロダクトを作るという流れでした。しかし生成AIやコーディングエージェント、バイブコーディングの普及によって、エンジニア以外の方でもコードを書けるようになり、プロダクトを作れるようになりました。これ自体は非常に素晴らしいことです。

一方で、生成されたコードの中身や、単に機能が実装されているかというレビューだけでなく、セキュリティ的に大丈夫かという観点を含めてレビューすることが、今まで以上に困難になってきています。

特に今年発表・報告された中で、生成AIを悪用した攻撃も報告されています。「スロップスクワッティング」と呼ばれる攻撃です。AIのハルシネーション、幻覚を利用して、いかにもありそうな名前のパッケージ、AIが生成しそうだけど本当は存在しないパッケージ名をあらかじめ公開リポジトリに登録しておくのです。

AIを使ってプロダクト開発やコードを書く側がその結果を鵜呑みにして、そのままパッケージをインストールしてしまうことで攻撃が成立します。まだ今年に命名・認知されたばかりで、実攻撃の観測はないとされていますが、これから生成AI活用が進むにつれて、実際の攻撃として観測されるのも時間の問題ではないかと考えています。

佐藤：3つ目は、日本のセキュリティ組織の構造的な課題です。日本の企業は非常に人材不足です。人材不足のため、セキュリティエンジニアやセキュリティの知見を持った方が、セキュリティ組織機能としてセントラルに集約されるような組織体系を持つ企業様が多いのではないでしょうか。

その結果、セキュリティ部門と開発部門、情報システム部門、外部ベンダーなど、各部門との間で組織構造的な分断が起きている状況にあります。また、セキュリティリスク管理のための基盤がきちんと整備されていないため、何かインシデントやリスクが発生した場合には、スプレッドシートやメール、Slackなどを通じて人力でセキュリティリスクに関する情報をやり取りしなければいけないという課題があります。

Question：直面する3つの課題

佐藤：ここまでの話を踏まえて、具体的な課題を整理してみます。特に今日、アーキテクチャカンファレンスということで、自社で開発している組織やプロダクト、技術選定やプロダクトの方針を決める立場の方が多くいらっしゃると思います。その方たちに向けて3つの課題を挙げます。可視化の課題、優先順位付けの課題、継続性の課題です。

1つ目の可視化の課題は、プロダクトを構成しているすべての要素、すべての依存関係を把握できていますか？という点です。特に生成AIが提示するOSSまで含めて追跡することが可能な状態になっていますかという課題です。

2つ目の優先順位付けの課題は、おそらく何らかの脆弱性スキャンツールを使えば非常に多くの脆弱性が検出されると思います。しかし、その中で本当に自分たちで対処しないといけない脆弱性がどれなのか分かるかどうか、またそれを決めるための指針があるかどうかという点です。

3つ目の継続性の課題は、セキュリティ対策を行えば行うほど開発スピードが落ちてしまうのではないかという懸念に関するものです。開発速度を落とさずに組織としてのセキュリティレベルを維持するにはどうすればいいか、手動管理のままで運用をスケールできるかどうかという課題です。

これら3つの課題は、多くの開発組織が直面している共通の悩みと言えるでしょう。

Answer：実践的な解決アプローチ

佐藤：一般的にITシステムにおけるセキュリティ対策としては、侵入対策や脆弱性診断を行われる企業様が多いと思います。WAF、IDS/IPS、ファイアウォールといった侵入対策や、半年に1回、年に1回といった定期的な脆弱性診断が中心になっているかと思います。これらは非常に重要な対策ではあるものの、不十分です。

佐藤：ITシステムは、アプリケーションのロジック、それぞれが依存するアプリケーションのライブラリやフレームワーク、そしてホストやコンテナ、アプリケーションが稼働する環境やインフラといった形で多層構造になっています。侵入対策やWebアプリケーション診断は、主にアプリケーションロジックのレイヤーをメインに診断するものです。

しかし先ほど申し上げたとおり、その下のアプリライブラリやホスト、コンテナ、インフラレイヤーがシステムを構成する大きな割合を占めています。実際の攻撃は、こうした防御の薄い、セキュリティ対策が不十分な領域を狙ってきます。ですから、脆弱性を根本から修正する脆弱性対策、脆弱性管理が必要になってきます。これは侵入対策と両輪で進めていくべきものです。

日常的な脆弱性管理をどうやって実現していくかというところで、最近よく言われているのがSBOM、ソフトウェアビル・オブ・マテリアルズです。SBOMはソフトウェアの構成表、いわばソフトウェアの部品表にあたります。

佐藤：製品やITシステムの内部にどんなソフトウェアが使われているのかを共通のフォーマットで定義し、関係者を含めて明確に把握できるようにするために進められているものです。SBOMがもたらす価値は4つあります。透明性の確保、リスク管理の効率化、迅速な対応、サプライヤー連携です。

ソフトウェアの構成要素を共通のフォーマットで可視化することで、依存関係まで含めて明確にできます。脆弱性のあるパッケージだけでなく、ライセンス情報なども含めて管理することが可能になります。構成要素が可視化されていれば、それらに対して見つかった脆弱性の早期発見につながりますし、影響範囲の特定もスムーズに行えるようになります。

サプライヤー連携については、自社の組織だけでなく外部のベンダーとも同じフォーマットで情報共有が効率化され、責任範囲の明確化や共同での対策実施が可能になります。最近では、各国のサイバーセキュリティのレギュレーションの中でも、SBOMの活用が必須要件になってきています。

SBOMの管理と継続的な脆弱性管理を実現するために、どういったソリューションが必要か、どういった要件が求められているかについてお話しします。

佐藤：1つ目は網羅性、カバー範囲の広さです。パブリッククラウドの脆弱性対策はこのツール、オンプレミスはこのツールという形でバラバラのツールを導入していると、管理が複雑化して結果的に見落としが発生します。できる限り1つのツールで統合的に扱えることが理想です。

2つ目は自動収集、自動連携です。SBOM自体はもともと手動で作るものではありませんが、ソフトウェア台帳のような資産台帳をExcelで管理していては、クラウドの利用が進む中でシステムの増加やインスタンスの生成・削除といった変化に追従できません。アカウントの連携やエージェントの導入だけで自動的に資産情報を収集できる仕組みが必要です。

3つ目は組織的な管理機能です。部門ごとやチームごとにリスクを管理し、それぞれの対応の進捗を比較できることが重要です。誰がいつまでに対応するのか、対応履歴がどうなっているのかといったところも含めて、トータルで管理できるツールやサービスが必要です。

yamoryの機能紹介

佐藤：yamoryはこれらの要件を満たすために設計しています。ITシステムを構成するライブラリ、フレームワーク、ミドルウェア、OS、ネットワーク機器からクラウド設定に至るまで、すべてのレイヤーをカバーしています。オンプレミス環境でもパブリッククラウド環境でもご利用いただけます。

また、多角的なリスク検知の機能を提供しています。ソフトウェアの構成情報をユーザーの方からお預かりする形になりますので、脆弱性だけでなく、EOLの検知、OSSのライセンス違反、クラウドの設定状況の検査といった、設定に誤りがないかも含めてトータルでリスク管理ができます。

組織的な管理機能についても充実しています。この後もご紹介しますが、オートトリアージによる対応優先順位の自動判定、チーム機能、対応状況の管理まで含めて提供しているサービスです。

佐藤：yamoryにはクラウドアセットスキャンという機能があります。従来のスキャンツールでは、各サーバーにエージェントをインストールしたり、スキャンのスクリプトを実行したりする必要がありました。しかしクラウド環境では、多ければ数百、数千のインスタンスが動的に生成・削除されるため、手動で設定作業をしていてはとても追いつきません。

yamoryのクラウドアセットスキャンは、お使いいただいているクラウドサービス、AWSやMicrosoft Azureのアカウントを連携するだけで、クラウド上の構成情報と設定情報をまとめて取得・可視化することができます。また、大元の管理アカウントを連携いただければ、その配下のアカウントも含めてすべてのアカウント、サブスクリプションの構成情報を一括でスキャンすることができます。

特に大規模な組織のお客様ですと、AWSのアカウントが数百あるようなケースもございます。導入の手間をかけることなく、設定が初日で終わって、次の日から全環境の脆弱性管理が利用可能な状態をつくることができます。

佐藤：次はオートトリアージの機能です。脆弱性スキャンツールを導入すると、膨大な数の脆弱性が検知されると思います。ただ、そのすべてが同じ緊急度とは限りません。実際に攻撃されている、あるいは攻撃されるかもしれないリスクが高いものから優先的に対応すべきという考え方です。

yamoryのオートトリアージは、3つの客観的根拠と、CISAというアメリカの団体が公表しているKEVカタログ、実際に攻撃が観測されている脆弱性のカタログを統合・加味した上で、対応の優先順位を決める機能です。

客観的根拠としては、1つ目に脆弱性スコアの高さ、2つ目に外部からのアクセス可否、つまり検出したソフトウェア資産やインフラシステムが外部からアクセス可能な状態になっているかどうか、3つ目に攻撃コードが流通しているかどうかといった情報も含めて優先順位を決めます。

この機能を活用することで、セキュリティの専門家が不在の組織、あるいは不足している組織であっても、効率的な脆弱性対応ができます。結果として業務負荷の軽減につながります。

佐藤：次はチーム機能です。yamoryの中では、セキュリティチームと開発チームという2つのチーム概念で整理しています。セキュリティチームは組織全体を管理する部門、開発チームは実際の開発に当たる部門や情報システム部門などを表現しています。

開発チームは、自分たちの管理対象を登録してリスク管理を行います。それぞれの部門が登録し、検出されたリスクをセキュリティ部門が横串で管理するという形で、複数組織を横断した統合的なリスク管理が可能になっています。

佐藤：対応状況管理機能についてもご紹介します。脆弱性が検出されたら、担当者および対応予定日を設定することができます。検出して終わりではなく、ステータスの状況、対応状況についても管理することが可能です。また、タイムラインにコメントを残して対応履歴をチームや組織を通じて情報共有することができます。

例えば、「このライブラリは別プロジェクトで検証済みだったから、バージョンアップしても問題ないでしょう」といった知見や、「この脆弱性は検出されているが、影響を受けないような形で設定されているから対応は不要です」といった判断根拠も含めて記録に残すことができます。これによって、脆弱性管理やセキュリティ対策にまつわる属人化を防ぎ、組織としてのナレッジを蓄積していくことができます。

活用事例

kubell様：脆弱性管理の標準化

佐藤：まずkubell様の事例です。脆弱性の有無の判断が属人化しており、重大な脆弱性を見過ごしてしまうかもしれないというリスクを課題としてお持ちでした。オートトリアージの機能が導入の決め手になりました。

この機能を使うことで、対応の優先順位がダッシュボードで一覧化されてメールでも通知される形になりました。結果として、社内の脆弱性管理が標準化されました。特にLog4jの脆弱性対策も、横断検索機能で影響調査が非常にスムーズに行われたという事例です。緊急時の対応力が大きく向上しました。

サイボウズ様：管理工数の大幅削減

佐藤：2社目がサイボウズ様です。もともと非常にセキュリティ対策に力を入れている企業様でしたが、膨大な脆弱性の管理工数が課題になっていました。OSSの管理台帳の作成や更新を手動でやられていて、毎月45人日かかっているという状況でした。

yamoryを導入いただくことで、35人日の工数削減を実現し、月あたりの管理工数をほぼ4分の1まで下げることができました。

KDDI様：バージョンアップの習慣化と開発スピード向上

佐藤：3つ目がKDDI様のケースです。自社の脆弱性状況が分かりづらいという課題があり、年数回のセキュリティ審査では脆弱性管理がきちんと行われているのか不安だったという課題感がありました。

yamoryを導入することで、ソフトウェアの脆弱性が見つかった際にすぐにバージョンアップするというプロセスが習慣化され、結果として開発スピードも向上しましたという声をいただいています。脆弱性が検知されたタイミングでビルドパイプラインを即時に止めて対応するという体制を作ることができました。

サキコーポレーション様：グローバル法規制への対応

佐藤：最後にサキコーポレーション様です。グローバルに製造業として事業展開されている企業様で、各国の法規制への対応が必要でした。

特にEUのサイバーレジリエンス法では、SBOMを使った脆弱性管理が必須という要件が定められています。グローバル展開する上で必要な要件でしたが、yamoryを導入することでSBOMフォーマットでの入出力が可能になり、こういった規制にも対応することができたという声をいただいています。

まとめ

佐藤：最後にまとめです。課題背景についてはお話ししてきたとおりですが、3つ覚えていただきたいポイントがあります。

• 対応すべきセキュリティリスク領域を決めた上で、網羅性、カバー範囲の広さをどのようにカバーしていくかを考える
• 自分たちのプロダクトやソフトウェアの資産、構成しているものを自動収集、自動連携するための仕組みを導入する
• 対策を属人的にせず、組織的なレベルで知見を共有しながら管理機能を充実させていく

こういったことを実現できるような対策をぜひ考えていただければ幸いです。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。