公開日 2026/04/17更新日 2026/04/17

【内製開発Summit 2026】大規模組織の内製開発を成功に導く、部門横断のセキュリティリスク管理手法とは

2026年2月25日、ファインディ株式会社が主催するイベント「内製開発Summit 2026」が、浜松町コンベンションホールにて開催されました。

本記事では、株式会社アシュアード「yamory」のプロダクトオーナー鈴木康弘さんによるセッション「大規模組織の内製開発を成功に導く、部門横断のセキュリティリスク管理手法とは」の内容をお届けします。

セッションでは、内製開発を進める中で見過ごされがちなセキュリティリスク管理の課題に焦点を当て、サイバー攻撃の最新事例やレギュレーションの高度化を背景に、部門横断でセキュリティレベルを揃えるための考え方とソリューション選定の観点が語られました。

■プロフィール
鈴木康弘
株式会社アシュアード
「yamory」プロダクトオーナー
ITコンサルティング会社を経て、2010年9月に株式会社ビズリーチへ入社。「ビズリーチ」の立ち上げ初期から携わり、「ビズリーチ」など4つのサービスや開発部門を立ち上げてきた。現在は自身が起案した「yamory」のプロダクトオーナーとして、事業やプロダクトのディレクションや組織マネジメントを行っている。また、一般社団法人ソフトウェア協会サイバーセキュリティ委員会の副委員長を務め、業界の脆弱性管理やSBOMの普及活動にも取り組んでいる。

アシュアードと脆弱性管理クラウド「yamory」

鈴木：株式会社アシュアードは、「ビズリーチ」を創業事業とする東証プライム市場上場のビジョナル株式会社100%出資のグループ会社です。サイバーセキュリティ領域で2つのブランドを展開しており、オンプレミスやパブリッククラウドの構成管理から脆弱性管理を行える「yamory」と、クラウドサービスのセキュリティ信用評価「Assuredクラウド評価」、取引先企業のセキュリティ信用評価「Assured企業評価」を提供しています。

「yamory」はお客様のソフトウェア資産やシステム構成をスキャンという形で登録していただき、逆側でさまざまなリスク情報を持ってきて、それらを照合して組織全体のリスクを可視化した上で、対応管理まで行えるツールです。トヨタ様やKDDI様といった大手企業から金融機関、製造業、さらには中央官庁まで幅広く利用されています。名前は出せませんが、皆さんが使っているようなデジタル庁様が作っているサービスの裏側でも動いていたりします。

私自身、「ビズリーチ」で開発部長を務めていた時に、製品ラインが5〜6個に増え、部門もいくつもできた中で、組織的にサイバーセキュリティのリスクをどう管理していくべきかという課題を感じたことが「yamory」立ち上げの原体験です。自分自身でこの「yamory」という製品を立ち上げてサービス化したという背景があります。

社会インフラまで及ぶサイバー攻撃の脅威

DXの進展に伴いシステムの数は増え続けていますが、その背後で動くさまざまなソフトウェアが攻撃対象になっています。最近の潮流として、単なる情報漏洩だけでなく、社会インフラに関わる攻撃が増えています。Log4Shellの問題、病院のシステム停止、サプライチェーン攻撃による自動車工場14工場28ラインの停止など、日頃からニュースで耳にする機会も増えました。

IPA（独立行政法人情報処理推進機構）が公表している「情報セキュリティ10大脅威」でも、ランサムウェアによる攻撃、サプライチェーン攻撃、システムの脆弱性を突いた攻撃が上位に入っています。ランサムウェア攻撃の手口を掘り下げると、ネットワーク機器の脆弱性を悪用して内部に侵入し、水平展開されてしまうというパターンが多く見られます。

開発者が知るべきマリシャスパッケージとミドルウェアのリスク

開発者に身近な事例を紹介します。一つはマリシャスパッケージの問題です。悪意を持った開発者がオープンソースにマルウェアを仕込むという攻撃で、GitHubのセキュリティアラートを分析すると、マリシャスパッケージの90%以上がNPMパッケージマネージャー上で展開されているというデータがあります。フロントエンドでTypeScriptを使って開発していると、ソースの中に入ってきてしまうケースがあるため、日頃からチェックする習慣がない開発組織だと、いつの間にか汚染されているということが起こり得ます。

もう一つはRedisの事例です。Redis自体をインターネット上に公開しながら運用するということはなかなかないと思いますが、それでも世界中で約6万台のサーバーがRedisのポートを開いた状態で公開されているというデータがあります。RedisShellという脆弱性はそういったサーバーを100%乗っ取れてしまうものでした。皆さんもキャッシュサーバーなどでRedisを使われるケースは多いと思いますが、何かの間違いで公開IPアドレスが振られていたりするとこういった危険性もあります。オンプレミスのものだけ脆弱性管理すればいいのではなく、AWSやAzureに乗っているものも含めて、使われているミドルウェアやOSの脆弱性リスクをきちんと管理していく必要がある時代になっています。

日本のセキュリティ人材不足と自動化の遅れ

さまざまな産業で各種レギュレーションが高度化しています。クレジットカード、金融機関、自動車工業会など、業界別にルールが更新され厳しくなり続けています。こうしたルールに従って脆弱性対応を期限内に行う運用が求められますが、人手が不足しているのが実態です。

データによると、日本のセキュリティ人材は「充足している」と回答した企業がわずか6.7%です。デジタル先進国のアメリカでは85.9%が充足していると回答しています。なぜこういった差になっているかというと、アメリカではセキュリティ業務の自動化が推進されていて、DXが進んでいる、省力化が進んでいるという背景があります。

実はセキュリティ業務は高度に見えて、結構地味なところもあります。いまだにExcelでサーバーをリストアップして脆弱性があるかないかを確認しているような企業もいるぐらい、手作業が残っている業態です。そこをどれぐらい徹底的に自動化していくかが問われているのが現状です。

内製開発で生じるセキュリティガバナンスの構造的課題

日本企業のほとんどは、各チームにセキュリティエンジニアが配置されておらず、少人数のセキュリティ部門が組織全体を見なくてはいけない「セントラル」型の構造になっています。

この構造だと、各チームの情報がセキュリティ部門にないため、情報収集から始まります。脆弱性診断の結果が何かのExcelシートやスプレッドシートでまとめられているようなケースも皆さん多いのではないでしょうか。こういったものがいろいろな形で残っているのが、日本の開発運用とセキュリティをつなぐところの根本的な課題だと考えています。

よくあるのが、もともと外部ベンダーに任せていたけれども、自社の内製チームを新たに作った。それは別で管理している。情シスもある。こういった形でいろいろな部門、チームが並列で開発はしているのですが、レギュレーションやルールに基づいて一定やらなければいけないという時に、どうやってガバナンスを効かせるのかというところが課題です。1つの開発部門はセキュリティレベルが高度でも、外部ベンダーに任せているところのレベルが低い。会社全体としてはレベルが低い部分がセキュリティホールになってしまいますので、全体の最低基準を引き上げて揃えるということが重要になります。

AIコーディング時代に高まるリスクの可視化の重要性

最近はAIによるコーディングも皆さん活用されているのではないでしょうか。私もCloud Codeなどでちょっとしたバグ修正であればもうやってしまおうかなという感覚があります。すごく便利なツールがいろいろ出てきていて、本来エンジニアから離れて管理職やプロダクトマネージャーの立ち位置にある人もAIエージェントで開発していくということになります。

そうなると余計にソースコードの中身がわからなくなるという問題が起きます。先ほどのNPMのようなパッケージマネージャーが勝手にパッケージを拾ってきてしまうので、いつの間にかマルウェアが入ってしまうこともあり得ます。AIはどんどん使っていきたいと思いつつも、中身がどうなっているのかに一定目を光らせる必要性は引き続きありますし、もしかしたら増えていくだろうと考えています。

セキュリティ対策の変遷で見ると、昔は境界型のファイアウォールで防いでおけばよいという時代がありました。最近だと脆弱性診断を半年に一回やっていますというケースもあるかと思います。ただ、先ほどのマリシャスパッケージやいろいろな問題がありますので、今の時代は毎日スキャンして、毎日今のリスクを確認していくということが求められるようになってきています。

部門横断のリスク管理に求められるソリューションの3つの観点

我々が提案したい、こうあるべきだと考えている姿についてお話しします。各部門にセキュリティの裁量が任せられているケースが非常に多いですが、それだとレベルがちぐはぐになります。セキュリティ部門から見ても一定のルールに基づいて全体のレベルが引き上がっていく、それをきちんとチェックできる仕組みが必要です。同時に各部門もそのルールに基づいて自律的にリスク管理を行える仕組みが重要になります。

そのためにはリスク情報と資産情報を集約管理し、一つのデータベースと共通のUI画面で、セキュリティ部門と開発部門が連携しながらリスク管理を行っていく必要があります。

こういった仕組みを作っていくにあたって、ソリューション選定で重要な観点は3つあります。ここからは我々がさまざまな企業の課題を聞く中で整理した、ツールに求められる要件をご紹介します。

1つ目は網羅性・カバー範囲です。オンプレミス環境とパブリッククラウド環境が混在している企業が大半ですが、部門ごとにバラバラなツールで管理していてはルールの徹底ができません。アプリケーションのライブラリだけでなく、ホストやコンテナ、クラウドの構成情報まで含めて同じツールで統合的に管理していくことが重要です。

2つ目は徹底的な自動化です。大規模なお客様ではAWSの環境が100、Azureも100といった規模感になります。組織管理用のアカウントから一斉に監視機能を展開し、設定は10分程度で完了。一度設定すれば日に1回は確実に全スキャンが実行されるような仕組みが求められています。

3つ目は組織的な管理機能です。子会社のアカウントの上に親会社のアカウントを置き、テナントをまたいでリスクを横断的に見ていく機能や、リスク単位での対応ステータス・担当者・対応予定日・対応履歴の管理が、部門横断のリスク管理には不可欠です。

まとめると、攻撃の多様化とレギュレーションの高度化でセキュリティ業務は一定のルールに基づいて行わなければならない時代になっています。SBOMをはじめとするより細かい単位での横断監視ができるセキュリティリスク管理体制が求められています。ソリューションを探す際には、網羅性・自動化・組織管理機能の3つの観点で評価していただくことをお勧めします。

本日はどうもありがとうございました。