2026年に報告されたCVEは、1日あたり前年比131%増加しています。

サプライチェーン

日本の重要インフラにソフトウェアを販売する

2026年10月1日、日本のサイバーセキュリティに関する2つの変更が施行されました。いずれも海外のソフトウェアベンダーを対象としたものではありませんが、どちらも重要インフラ事業者がサプライヤーに求める水準を引き上げます。何が変わったのか、顧客から何を求められるようになったのか、そしてそのうちどの要求にビルドで応えられるのかを解説します。

更新日

2026年10月1日に何が変わったか

この2つの変更はひとまとめに語られることが多いものの、法的な位置付けも対象も異なります。

能動的サイバー防御法 統一基準
概要 令和7年法律第42号(サイバー対処能力強化法) 2026年7月31日にサイバーセキュリティ戦略本部が決定した基準
対象 指定を受けた基幹インフラ事業者 政府機関等、およびそれを通じて重要インフラ16分野の事業者
求める内容 重要な設備の届出と、政府へのインシデント報告 ガバナンスやサプライチェーンリスクから脆弱性管理まで、分野横断のセキュリティ対策
拘束力 罰則付きの法的義務 それ自体に強制力はない。各分野の安全基準を通じて事業者に及ぶ

16分野とは、情報通信、金融、航空、空港、鉄道、電力、ガス、政府・行政サービス、医療、水道、物流、化学、クレジット、石油、港湾、郵便です。

基準とあわせて、日本の国家サイバー統括室は安全基準等の策定のための指針を公表しており、これも10月1日から適用されています。事業者が調達先の企業について何をすべきかが具体的に示されているため、サプライヤーにとって最も役立つ文書です。

なぜサプライヤーに影響が及ぶのか

義務を負うのは事業者であるため、サプライヤーへの影響は法的なものではなく商取引上のものです。契約条件、調達基準、質問票という形で届きます。個々の顧客に何が適用されるかはその分野と顧客自身の安全基準によって異なるため、推測せずに顧客に確認してください。

統一基準は事業者に対し、重要なシステムがサプライチェーンにどう依存しているかを把握すること、サプライヤーのセキュリティの状況を知ること、製品やサービスの調達時にセキュリティ要件を定めることを求めています。指針はそれを具体的な項目に落とし込んでいます。

事業者から求められうること

指針は、事業者が講ずべき対策と、講ずることが望ましい対策を区別しています。次の表は両方を示し、そのエビデンスのうちビルドから得られる部分を記載しています。

指針の記載内容 レベル ビルドから得られるエビデンス
契約に盛り込むセキュリティ要件。重大な脆弱性の対応と報告の方法などが例示されている(2.9 ②-2) 講ずべき トリアージから修正リリースまでの各脆弱性の記録
調達したシステムのサプライヤーが、保守契約に基づいて脆弱性を報告、対応、開示する(3.6 ①-2) 講ずべき 出荷したものの継続的な監視と、各脆弱性が影響するリリース
脆弱性やインシデントが見つかった際に、サプライヤーと迅速に情報共有する手段(2.9 ③-3) 講ずべき どのリリースにパッケージが含まれているかを示すビルド履歴
調達に透明性が必要な場合に、サプライヤーにSBOMの作成と提供を求める(2.9 ③-4) 望ましい ビルドごとのSBOM(CycloneDXまたはSPDXでエクスポート)
サプライヤーがセキュアなソフトウェア開発手法に沿って開発していることの確認(2.9 ③-4) 望ましい 分離されたビルドジョブと、適用されるエグレスポリシー

日本ではSBOMが義務付けられているのか

統一基準のもとでは義務ではなく、統一基準にSBOMへの言及はありません。指針はSBOMを選択肢の1つとして挙げています。調達に透明性を必要とする事業者はサプライヤーにSBOMの作成と提供を求めることができ、指針は経済産業省のSBOM導入の手引(バージョン2.0)を参照しています。それでも、求められた場合には応じる価値があるでしょう。契約によって、選択肢が自社に対する義務になりうるからです。

顧客が確認する可能性のあるその他の事項

  • 第三者評価。指針は、サプライヤーの確認にかかる負担を減らすために外部評価を活用することを提案しています。ISMS適合性評価と、経済産業省および国家サイバー統括室によるSCS評価制度が挙げられており、後者は2026年度末ごろに開始される予定です。
  • 製品・サービスの制度。選定基準を設ける際の参考として、IoT製品向けのJC-STAR、クラウドサービス向けのISMAP、IT製品向けのJISECも示されています。
  • 脆弱性診断。事業者は自社システムの定期的な診断を行っており、契約条件によって診断と報告がサプライヤーにも及ぶことがあります。
  • データに関する条件。契約では、データの所在、保存、保管、移転、廃棄について定められることがあります。

すでにCRAへの準備を進めている場合

多くの作業はそのまま活かせます。EUのCyber Resilience Actは独自の義務を持つ別の制度であるため、それを満たしても日本の顧客の要求を満たすことにはなりません。しかし、どちらも突き詰めれば同じ問いに行き着きます。出荷したソフトウェアに何が含まれているか、脆弱性がどのリリースに影響するか、それに対して何をしたか、です。これらの答えがビルドから得られるなら、改めてまとめ直すことなく日本の顧客にも再利用できます。

CRACIの役割

CRACIは各GitHub Actionsジョブが実際に取り込んだものを記録してビルドからSBOMを生成し、出荷したものを監視して、トリアージから修正リリースまで脆弱性を追跡します。これにより、上の表にある要求に対するエビデンスが得られます。

ただし、事業者が求めうるもののうち一部しかカバーしません。CRACIは脆弱性診断やペネトレーションテストを実施せず、デプロイ済みシステムへのパッチ適用も、日本の当局への報告も行いません。いかなる分野の基準への準拠も保証するものではありません。CRACIは欧州でホストされており、保有する認証はISO/IEC 27001のみです。この2点を顧客のデータに関する条件と選定基準に照らして確認してください。

日本の重要インフラに関するよくあるご質問

能動的サイバー防御法は海外のソフトウェアベンダーにも適用されますか?

届出とインシデント報告の義務を負うのは、指定を受けたインフラ事業者です。サプライヤーには、そうした顧客が契約で求める内容を通じて影響が及ぶ可能性が高いため、顧客と法律顧問に確認してください。

統一基準は義務ですか?

それ自体に強制力はありません。主に政府機関等を対象とし、各分野の安全基準に盛り込むべき内容を示すものであるため、事業者を拘束する内容はその分野によって異なります。

対象となる分野は何ですか?

16分野です。情報通信、金融、航空、空港、鉄道、電力、ガス、政府・行政サービス、医療、水道、物流、化学、クレジット、石油、港湾、郵便です。

日本ではSBOMが義務付けられていますか?

統一基準のもとでは義務ではなく、統一基準にSBOMへの言及はありません。安全基準等の策定のための指針は、事業者がサプライヤーに求めることができるものとしてSBOMを挙げており、契約によってそれが義務になることがあります。

脆弱性管理の項目では何が求められていますか?

統一基準の3.3.6は事業者に対し、脆弱性が稼働中のシステムに影響するかを確認し、システムを定期的に診断し、パッチ適用の手順を定めることを求めています。その際、AIによって発見から悪用までの時間が短くなっていることを考慮するよう求めています。

CRAへの準備で日本の要件もカバーできますか?

いいえ。ただし、エビデンスの多くはそのまま活かせます。SBOM、脆弱性が影響するリリースの記録、その対応の記録は、どちらの場合にも役立ちます。

顧客から求められうるエビデンス

すべてのGitHub ActionsジョブからSBOMと脆弱性の記録を、手作業で作成することなく取得できます。

デモを予約