欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用

欧州CRAに対応するための要件を解説

Covalent株式会社 Managing Directorの小林弘樹氏は、欧州サイバーレジリエンス法(CRA)の概要と脆弱性報告義務対象、SBOMによる脆弱性可視化の運用について解説した。

Covalentは、サイバーセキュリティや先端技術について、調査・コンサルティングを提供する企業だ。テクマトリックスとも提携してソフトウェアサプライチェーンのセキュリティ・コンプライアンスのためのSBOM関連支援を提供している。

まず、CRA概要とその策定の背景について。

現在では、IoT機器をはじめネットワークにつながる製品が増えた。これにより、サイバー攻撃にさらされるリスクが高まり、攻撃による情報漏えいやインフラ停止などの被害も増加している。こうした背景からIoT機器をはじめとした「デジタル要素を備えた製品」のサイバーセキュリティをEU域内で統一して強化する法律としてCRAが策定された。

タイムラインとしては、2022年に法案・素案が公表され、2024年11月に最終版がEU官報に掲載されて2024年12月に発効となった。2026年9月11日からは積極的に悪用されている脆弱性および深刻なインシデントの報告義務が先行適用され、2027年12月11日から全面適用される。

CRAはEU域内の法律だが、世界各国でも製品のサイバーセキュリティに関する規制・認証制度の整備が進められており、相互に影響し合っている。

CRAの目的はサイバーセキュリティ強化であり、そのために脆弱性を最小化することや、開発から販売後までの製品ライフサイクル全体での対策、製品やサポートの情報の透明性などを求めている。

CRAの対象製品の分類は、クリティカル製品、重要製品クラスI、重要製品クラスII、デフォルトカテゴリの4分類に分けられている。大体の製品はデフォルトカテゴリに区分されるが、重要製品は、クラスIIでは第三者機関による適合性評価が必須であり、クラスIも整合規格などを全面適用していない場合は第三者機関による評価が必要になるので注意したい。

なお、医療機器や体外診断用医療機器、自動車、航空製品、船舶用機器など、CRA第2条が個別に列挙するEU法規制の対象となっているものは、CRA対象外となっている。一方、機械規則や無線機器指令(RED)の対象製品は、これらの列挙に含まれないためCRAの対象となる。

CRAの義務内容は製品ライフサイクルにわたるもので、開発時、上市(ローンチ)時、上市後に分かれる。

開発時には、セキュリティ仕様の実装や、セキュア開発プロセスの導入、脅威・リスク分析、セキュアコーディング、セキュリティ検証が求められる。また上市時には、CRA適合の技術文書を作成し、適合性評価を実施することが求められる(デフォルトカテゴリの製品は自己評価が可能)。

そして上市後には、脆弱性を継続的に監視し、積極的に悪用されている脆弱性や深刻なインシデントを決められた時間内に報告することが求められる。なお、継続的な監視やSBOM作成といった脆弱性ハンドリングの義務が適用されるのは2027年12月11日からで、2026年9月11日に先行適用されるのは報告義務のみである。

開発プロセスでは、設計や実装、テストのそれぞれで脆弱性を防ぐ対策が求められる。ただし、OSS開発コミュニティ自体に製造者と同じ義務が課されるわけではなく、OSSを組み込んだ製品を販売する製造者が義務を負う点に注意が必要だと小林氏は呼びかけた(なお、OSSの開発を継続的に支援する法人は「オープンソースソフトウェア・ステワード」として軽量な義務を負うが、制裁金の対象からは除外されている)。

上市時に求められる技術文書は8種類あり、その中の1つとしてSBOMを作ることが義務づけられている(技術文書は当局に提出するものではなく、作成・保管したうえで、市場監視当局からの理由付きの要求に応じて提供する)。ただし、技術文書として作成するSBOM(最低限、最上位の依存関係を記録)と、脆弱性監視に使うSBOM(すべての依存関係を記録)とでは目的が異なると小林氏は付け加えた。

CRAのSBOMにおいて、対象範囲は、自社開発のプロプライエタリソフトウェアと、商用外部調達ソフトウェア(COTS)、OSSとなっている(この3分類はCRA原文の区分ではなく、一般的な実務上の整理)。

上市後については、前述のとおり2026年9月11日から、報告義務が開始される。報告先はENISAの単一報告プラットフォーム(SRP)経由で、主要拠点が所在する加盟国のCSIRT(coordinatorに指定されたもの)とENISAの双方に同時に通知する。対象は、積極的に悪用されている脆弱性と、深刻なインシデントだ。

積極的に悪用されている脆弱性とは、悪意ある行為者がシステム所有者の許可なく悪用したという信頼できる証拠がある脆弱性で、その手がかりとしては米CISAのKEV(Known Exploited Vulnerabilities)や欧州ENISAのEUVD(EU Vulnerability Database)などが利用できる(ただし2026年7月27日公表の欧州委員会ガイダンスNo.218により、判断の主眼は他社システムでの悪用実績の有無ではなく、自社製品において当該脆弱性が悪用され得るか、実際に悪用されているかに移っている。KEVやEUVDへの掲載は監視の手がかりであり、報告義務の判断基準そのものではない)。

また、深刻なインシデントは「機密・重要データまたは機能の可用性/真正性/完全性/機密性を保護する能力への悪影響」「悪意あるコードの導入・実行を導く事象(ユーザーのネットワーク・情報システムを含む)」のいずれかをもたらす、またはその可能性がある事象と定義されている。

サポート期間(原則5年以上。製品の期待使用期間が5年未満の場合はその期間)中は脆弱性を継続的に監視し、積極的に悪用されている脆弱性または深刻なインシデントを認知した際には24時間以内に早期警告通知を行う。なお、脆弱性ハンドリングの義務はサポート期間中に限られるが、報告義務はサポート期間終了後も継続する。続いて72時間以内に、脆弱性通知(インシデント通知)として、適用済みの緩和措置やユーザーが取れる緩和措置などを報告する。

その後の最終報告については、脆弱性とインシデントとで変わる。脆弱性の場合は、是正措置または緩和措置が利用可能となってから14日以内に報告する必要がある。またインシデントの場合は、72時間での報告を起点として1か月以内に、インシデントの詳細や、脅威の原因、進行中の緩和措置について報告する必要がある。

CRAだけでなく、脆弱性監視としてのSBOMの使い方についても小林氏は言及した。

ステップとしては、監視対象となるOSSを一覧表にする「SBOM作成」、SBOMに記録されたコンポーネントについてNVDやEUVD等の脆弱性データベースから情報を取得する「脆弱性DB突合」、同様に自社製品への「影響判定」、見つかった脆弱性の対応優先順位を判断する「トリアージ」、最終的な「報告・修正」、の5ステップからなる。

こうした一連の業務をすべて手作業で行うのは負荷が大きいため、SBOMツールを使うことで効率化できる。そのSBOMツール選定のポイントとして、対象ソフトウェアの広さや、登録できる情報項目、依存関係をどこまで深く検出できるか、対応するSBOMフォーマットの種類、ソースコードやバイナリなどのスキャン対象のカバレッジ、脆弱性DBとの連携、CI/CDパイプラインやチケットツールとの連携などの運用時の利便性を小林氏は挙げた。

CRA対応に話を戻すと、必要な取り組みとして、製品脆弱性を扱うPSIRT(Product Security Incident Response Team)の整備を小林氏は説明した。

そして9月の報告義務施行に向けた準備のロードマップとして、「PSIRT体制の構築と、PSIRTが何をするかという規定をまとめておくことが最低限。あとは、業務設計ができていることが望ましい」と小林氏は語った。

最後に小林氏は、CRA対応について、条文の理解から始めると企業の負担が大きくなると指摘。「法律知見のあるコンサルを活用して対応を進めることで、内容理解やダブルチェックに役立つかと思う」と参加者に説明した。

AIコーディング時代は
「隠れた依存関係」を検出して管理可能なリスクに

SBOM管理を含むSCA(Software Composition Analysis：ソフトウェア構成分析)ツール「Insignary Clarity」を開発するInsignary Inc.のChief Strategy Officer(最高戦略責任者)であるMike Pittenger氏が登壇。SCAツールとそのニーズの移り変わりの歴史をふまえて、AI生成コードの時代のリスクとそれに対するSCAツールの役割、そしてClarityの特徴について語った。

Pittenger氏は冒頭で、オープンソースのリスクに対するポイントが、OSSのライセンスリスクと、構成ソフトウェアの脆弱性によるセキュリティリスクの間を振り子のように揺れ動いてきた歴史を紹介した。

まず2000年代。ソフトウェア開発者はOSSをコード開発に利用するようになってきたが、組織としてはそれを把握していなかった時代だ。SCAツールが登場したのもこの頃だ。この時代のSCAツールは、「ライセンスやコンプライアンスのリスクを管理する法務主導のもので、セキュリティ目的ではなかった」とPittenger氏は語った。

続いて2010年代。この時代でも当初はSCAがセキュリティ目的ではなく法務主導のものだった。

しかし、2014年にOpenSSLの脆弱性「Heartbleed」やBashの脆弱性「Shellshock」などが発見され、基盤となるOSSの脆弱性の問題が一般ニュースでも知られるようになった。それにより、SCAツールがセキュリティにおいて重要なものになり、新規参入や大企業による買収が活発になったとPittenger氏は語った。そして2018年には、OSSは開発におけるメインストリームとなった。

このとき、Clarityのような本格的なツールであれば膨大なソースコードをスキャンしてフィンガープリントをデータベース化する。しかし、簡易的なツールではPOMファイルのようなプログラミング言語のパッケージマネージャーの設定ファイルから依存ソフトウェアを検出するのだという。「この方式は高速で有用だが、すべての依存関係が宣言されているという前提に立っている。これは人間の開発者であればたいてい満たされるが、AIが開発するようになると破綻する」とPittenger氏は指摘した。

そして2020年代はAIがコーディングするようになり、「隠れた依存関係」が問題になってきた。人間の開発者はメンテナンスの負荷を減らすため、できるだけ既存のライブラリを使うが、AIにはその動機がないため、しばしば学習したOSSのコード片をそのままコピー＆ペーストで自分のコードに入れてしまう。そのため、宣言された依存関係を分析するSCAツールでは発見できない。

その結果として、表示義務などのOSSライセンス違反や、知的財産権の侵害のリスクが発生する可能性が懸念されている。実際に2022年に、OSS開発者たちがGitHubとMicrosoft、OpenAIを相手に訴訟を起こしており、地裁で請求の大半が退けられ、争点が大幅に絞られたうえで控訴審に係属中だが、「これが未対策のリスクの兆候を示していると考えることを提案する」とPittenger氏は語った。

では、AIによってどのぐらいOSSコードが混入するか。「LiCoEval」(License Compliance Evaluation)と呼ばれる研究報告(2024年8月公開、ICSE 2025採録)では、世界中のコードを分析する「World of Code」データセットから4,000以上(4,187件)のPython関数の機能の説明を作成し、それを14の人気あるLLMに与えてその機能を再現するよう指示したところ、生成された関数のうち、上位モデルでも0.88～2.01%が元コードと非常に似たコードを生成したことがわかった。

またInsignary社も、Clarity for AI Risk(Clarity AIR)を使って20～30のアプリケーションを調査したところ、AIによって生成された部分のあるアプリケーション全体ではファイルの37%に隠れたスニペットが存在し、100%をAIが生成したアプリケーションではファイルの56%が隠れたスニペットを含んでいることがわかったという。さらに、従来のSCAでは23%しかカバーしていなかったとPittenger氏は指摘した(これらはいずれもInsignary社が公表した自社調査の値であり、標本規模は限定的である)。

この状況に対して、リスクチームは何をすべきか。「この脅威が現実であること、既存のツールで検出できないこと、全体に影響する問題であることがわかったと思う。しかし幸いなことに、この問題はオープンソースですでに経験済みで、対処可能だ」とPittenger氏は言う。

Pittenger氏の言う対策は、ガバナンス、技術的管理、プロセスの組み合わせとなる。ガバナンスの面では、AI生成コードに関する明確なポリシーを策定し、AI生成コードを慎重に扱うことを徹底する。技術の面では、宣言に頼らないスニペットレベルのスキャンをワークフローに組み込み、完全なSBOMを取得する。プロセスの面では、スニペット単位の検証を実行して、問題があるコードは削除するか修正するプロセスを、大規模展開する前に整備する。

「これらを組み合わせることで、現時点では見えないリスクを、管理可能なリスクに変えることができる」とPittenger氏は語った。

テクマトリックスのSBOMソリューションを紹介

テクマトリックス株式会社のソフトウェアエンジニアリング事業部の柳田誠氏は、同社が扱う、Insignary Clarityを含むSBOMツール関連の製品やサービスを紹介した。

テクマトリックスで扱っているSCAツールは2種類。バイナリとソースコードのスキャンに対応したInsignary社の「Clarity」と、ソースコードのスキャンに対応したFossID社の「FossID」だ。

この2つのツールの役割は補完関係にあり、また最近は両者ともSBOMツールとしての引き合いが多いという。

ここで改めて、柳田氏はSBOMツールの必要性を説明した。

自社製品が使っているOSSについて、コンプライアンス(ライセンス)やセキュリティ(脆弱性)を守るためには、利用しているOSSとそのバージョンを把握して管理する必要がある。それを行うのがSBOMツールだ。

脆弱性については、使っているOSSを管理することで、それらのOSSに新たな脆弱性が発見された場合、通知してくれる。特にソフトウェアサプライチェーンが複雑化する中では、バイナリになっているものを含めてすべての要素についてSBOMを作ることが有効になる。

またライセンスの問題については、生成AIによるコーディングでOSSのコードの一部が意図せず入り込むことがある。そこで、OSS全体だけでなくスニペット(コード片)を検出する機能も重要だ。

「手作業でこれらをチェックするのは非常に難しい。ツールをうまく活用して、作業の効率化と時間の短縮を図るのがよいと考えている」(柳田氏)

続いて、各SCAツールの紹介。まずは「Insignary Clarity」だ。

Clarityの最大の特徴は、ソースコードに加えてバイナリのスキャンに対応していることだ。バイナリに残るソースコード情報の断片からマッチするOSSを探すもので、「バイナリスキャンに対応したツールはほかにもあるが、Clarityは非常に精度がいいのが特徴」と柳田氏は言う。

また、バイナリを含めたスニペット検出にも対応している。

Clarityの実際の画面イメージも柳田氏は紹介した。スキャン結果はコンポーネントリストに表示され、検出されたOSSのバージョン番号もわかる。

OSS名からは、そのソフトで見つかっている脆弱性情報をセキュリティリスクリストで見られる。また、そのOSSに関する訴訟事例も確認できる。

Insignary Clarityの提供形態は2通りある。

「ハイブリッド環境」では、社内にオンプレミスでClarityのアプリケーションサーバーを立てて、そこに検査対象のソフトウェアを送る。インターネット経由で送られるのは、照合のためのフィンガープリントだけだ。この形態では検査対象の自社ソフトウェア自体をインターネット経由で送信する必要はないのが特徴だ。

また「SaaS環境」では、Clarityのアプリケーションサーバーもインターネット経由で利用する。この形態では、環境構築が不要になるのが利点だが、検査対象の自社ソフトウェアをインターネット経由で送信して問題ない場合に限られる。

続いて「FossID」の紹介だ。OSSを識別するツールという点はClarityと同様だが、対象はソースコード。コンプライアンス(ライセンス)とセキュリティ(脆弱性)の両方を得意とする。

FossIDの特徴は、業界最大規模のデータベースを持っていることだ。特に2億プロジェクト(FossID社公称値)のOSSのナレッジベースを備えているため、見つけられる可能性が高くなる。

FossIDの提供形態は、Clarityでいうハイブリッド環境と同様のものだ。社内にウェブアプリケーションサーバーを立てて、そこに検査するソースコードを送り、ハッシュ値とデータベースの照合についてだけインターネット経由のサーバーとの通信が行われる。そのため、社外にソースコード自体を送ることはない。

FossIDの実際の画面イメージも柳田氏は紹介した。Scan Viewには検出結果が表示され、脆弱性の警告やライセンスの種類なども表示される。またスニペットが検出された場合は「マッチ」の欄に「partial(部分的)」と表示され、検出対象と比較対象の合致箇所を並べて表示できる。「ここのスニペット検出の精度が非常にいいのがFossIDの特徴の1つ」と柳田氏は言う。

ClarityとFossIDをそれぞれ使った「SBOMレポーティングサービス」も、テクマトリックスでは提供している。

ソースコード用SBOMレポーティングサービスでは、顧客のソースコードをFossIDにかけて、SBOMと分析レポートにまとめる。主に、急遽SBOMが必要な状況が発生したときなどのスポット利用を想定している。

バイナリ用SBOMレポーティングサービスも、顧客のバイナリファイルをInsignary Clarityにかけて、SBOM分析レポートにまとめる。

そのほかSCAツール以外にも、ソースコード品質向上のための解析ツールや、ソフトウェア開発のダッシュボードツールなど、幅広いツールをテクマトリックスでは扱っていると柳田氏は紹介し、「ソフトウェアの品質や管理、検証に課題があったら、ぜひお問い合わせを」と参加者にアピールした。