サイバーレジリエンス法の24時間報告義務に備える4つの問い

2026年9月11日以降、欧州連合（EU）市場にソフトウェアを投入する多くの企業は、自社製品の脆弱性が実際に悪用されていると知った時点から24時間以内に報告する義務を負います。これはサイバーレジリエンス法（CRA）で新たに定められた要件です。CRAは、欧州で販売されるデジタル要素を含む製品にサイバーセキュリティ要件を課すEU法。製品がセキュア・バイ・デザインで設計され、新たな脅威に対しても継続的に保護されるようにすることを目的としています。なかでも最も厳しい要件が課されるのは、これらの製品を製造する事業者。大手ソフトウェアベンダーから、ネットワークに接続するハードウェアを出荷する企業まで、幅広く対象になります。

コンプライアンス上の難所は、報告書の提出そのものではありません。出荷済みの製品に含まれる脆弱性が、ソフトウェアサプライチェーンのなかで実際に悪用されていると、十分な速さで気づけるかどうかです。24時間のカウントダウンは気づいた瞬間から始まる。だからこそ検知が決定的に重要になります。継続的な検知は、一度きりのコンプライアンス対応ではなく、エンジニアリングで解くべき課題。GitLabのソフトウェアサプライチェーンセキュリティ機能は、出荷済みの成果物に対する悪用の兆候を自動かつ継続的に捉えるために設計されています。本記事では、自社のパイプラインにおける継続的な検知体制をいま見直すための4つの問いを取り上げます。

報告義務は2026年9月から始まる

2026年9月11日以降、製造業者は悪用が確認された脆弱性を認識してから24時間以内に報告しなければなりません。報告は3段階に分かれ、いずれも欧州連合サイバーセキュリティ機関（ENISA）と、調整役に指定されたコンピュータセキュリティインシデント対応チーム（CSIRT）の双方へ同時に提出します。

1. 早期警告：悪用されている脆弱性を認識してから24時間以内 悪用が起きている事実を伝える短い第一報です。この時点で影響範囲の全体像や修正方法まで把握している必要はありません。
2. 通知：72時間以内 影響を受ける範囲、現時点で判明している内容、そして講じている対応を、より詳しく報告します。
3. 最終報告 悪用されている脆弱性の場合、是正措置または緩和策が利用可能になってから14日以内に提出します。

GitLabが答えを導く4つの問い

自社製品の脆弱性が報告対象にあたるかどうかを判断するのは、あくまで自社の役割です。ここでは、CRAに備えるためにいま自問しておきたい4つの問いと、それぞれにGitLabがどう答えられるかを紹介します。

出荷済みの製品で悪用が起きていないかを見つける

出荷した製品のコンポーネントが、いま実際に悪用されていないか

継続的依存関係スキャンはSBOMを常時監視し、新たに公開されたセキュリティ勧告との突き合わせ結果を通知します。各検出結果に付与されるKEVステータスとEPSSスコアを見れば、攻撃者が現に悪用しているものを見分けられるため、実リスクの高い脆弱性から優先的に対処できます。コンテナスキャンは出荷するイメージを、運用コンテナスキャンは現在クラスターで稼働しているものを、それぞれカバーします。

影響を受ける製品とリポジトリをすべて洗い出す

どの製品が影響を受け、どのリポジトリに含まれているのか

グループレベルの依存関係リストで一度検索すれば、そのコンポーネントを含むすべてのプロジェクトが返ってきます。セキュリティ属性を見れば、インターネットに公開されているものやビジネス上重要なものも判別可能。どこから着手すべきかがすぐに見えてきます。このリストに情報を供給する経路は2つ。ひとつは依存関係スキャンが生成するCycloneDX形式のSBOMで、推移的依存関係を含めてコードが宣言している内容を反映します。もうひとつはコンテナスキャンによるSBOMで、こちらはイメージに組み込まれたOSパッケージをカバー。一度の検索でソフトウェアサプライチェーン全体、つまり実際に出荷したものすべてに到達できます。

脆弱性をいつ把握したかを記録に残す

いつ気づいたかを証明できるか

各脆弱性のアクティビティログには、検出された日時とパイプライン、そしてその後のすべての状態変更が、担当者と時刻とともに記録されます。脆弱性イベントのWebhookを使えば、同じ記録を時刻管理に用いているシステムへそのまま送り込めます。いつ把握したのかを問われたとき、答えはすでに残っている状態です。

修正をいつ出荷したかを示す

修正はリリースされたか、そしてそれはいつか

依存関係スキャンの自動修正が、アップグレードのマージリクエストを自動で作成します。マージリクエスト承認ポリシーでは既知の悪用ステータスを条件にゲートを設けられるため、都度議論を蒸し返すことなくルールが機能し続けます。これらの土台となる統制はコンプライアンスフレームワークで定義。コンプライアンスステータスレポートが各プロジェクトの適合状況を追跡し、コンプライアンス違反レポートが漏れを拾い上げます。

すでに動いている仕組みでカバーできること

CRAの報告義務を判断するために必要な情報の多くは、コードが置かれているGitLabプラットフォームにすでに存在します。インベントリ、悪用のシグナル、継続的な再照合、タイムスタンプ、ポリシーゲート。これらは、評価して購入し、連携させなければならない5つの別々のツールではありません。すでに運用しているパイプライン上で有効化するだけの機能であり、新たなエージェントもデータプレーンも不要です。

静的アプリケーションセキュリティテスト（SAST）、シークレット検出、シークレットプッシュ保護、Infrastructure as Code（IaC）スキャンといったGitLabのセキュリティスキャン、そしてセキュリティポリシーは、ここまでの4つの問いに答えるうえで必須ではありません。ただし、2027年12月に到来するCRA要件の次のフェーズへの備えとしては有効です。

先を見据えて、危険なパッケージをサプライチェーンに入れる前に止める

GitLabのセキュリティ機能は、迅速な対応を支えます。同時に、そもそも報告すべき脆弱性を減らす環境づくりにも目を向ける価値があります。

サプライチェーンのリスクは、すべてがCVE（共通脆弱性識別子）として現れるわけではありません。チームが日常的に入力しているライブラリと1文字だけ違う名前で公開されたパッケージには、セキュリティ勧告も重大度スコアも付きません。AIアシスタントが実在しないパッケージ名を生成し、それを第三者が登録したケースも同じ。パッケージそのものが攻撃である以上、修正すべき対象は存在しません。

そこでGitLabは、3週間後のレビューで脆弱性を検出するのではなく、レジストリの段階で予防的なポリシーを適用できる仕組みを近く提供します。有害なパッケージがビルドに到達する前に、サプライチェーンへの侵入を防げるようになります。まもなく開始する依存関係ファイアウォール（Dependency Firewall）のクローズドベータについては、こちらのフォームからお問い合わせください。

すでにGitLabをご利用の場合は、コンポーネントをひとつ選んでお試しください。 グループレベルの依存関係リストを開き、製品に含まれていると分かっているものをひとつ選び、4つの問いすべてに答えるまでにどれだけ時間がかかるかを計測してみましょう。短時間で答えが出るようであれば、継続的な依存関係スキャンを有効化し、マージリクエスト承認ポリシーに既知の悪用ステータスを条件として追加してください。

まだUltimateプランをご利用でない場合は、 出荷済みのコンポーネントに実際に悪用されている脆弱性が含まれていないかを、ひとつの画面で確認できます。無料トライアルを開始してください。

さらに詳しく知りたい方は、以下もあわせてご覧ください。欧州委員会によるサイバーレジリエンス法の概要、報告義務のページ、法令テキストの要約、そして委員会による実装ガイダンス。