2026-09-07 • 読了時間: 12分

サイバーレジリエンス法が銀行に届く：SBOMとソフトウェア・サプライチェーン

2026年9月11日、EUサイバーレジリエンス法（CRA）の報告義務が発効し、2027年12月11日には残りの規定が全面適用されます。多くの銀行はCRAを「製品規制であり自行には関係ない」と整理してきました。最初の読みとしては妥当でしたが、二度目としては高くつきます。CRAは、供給者が貴行に負う義務を書き換えます。そしてDORAはすでに、その供給者が納めたものについて貴行の責任を問うています。

銀行のロードマップに誰も書かなかった期限

規則 (EU) 2024/2847、すなわちサイバーレジリエンス法は、長い移行期間を伴って2024年12月に発効しました。多くの金融機関はこれを他人事として読みました。規制の対象は、EU市場に上市されるデジタル要素を有する製品です。ルーター、産業用制御装置、オペレーティングシステム、ライブラリ、ファームウェア。銀行は一見、そのいずれも製造していません。義務はベンダー側にあるように見え、この案件は「経過観察」の山に積まれました。

その山は、いまや期限切れです。2026年9月11日以降、製造者は積極的に悪用されている脆弱性と重大なインシデントを、ENISAのシングル・レポーティング・プラットフォームを通じて、24時間・72時間・14日という刻みで報告しなければなりません。2027年12月11日からは、必須要件とCEマーキングが全面的に適用されます。この二つの日付のあいだに、銀行の資産に関わる主要な供給者は、構成要素の文書化、脆弱性の開示、サポート期間の約束のしかたを作り直します。CRAをベンダーの問題と見なしてきた金融機関は、それが契約の問題として、インシデント対応の問題として、そして一部にとっては自行の名前が記された問題として届くことを知るでしょう。

CRAは何を規制するのか、そして貴行を規制するのか

CRAが捉えるのは市場に上市される製品であり、顧客向けに運用されるサービスではありません。純粋なSaaSは適用範囲外です。そこはNIS2の領域です。ただし、それなしには製品が機能を果たせないリモートデータ処理ソリューションである場合は別です。商業活動の外で提供されるフリー／オープンソースソフトウェアも範囲外であり、オープンソースのスチュワードには意図的に軽い規律が用意されています。銀行の内部資産の大半――勘定系、データ基盤、社内ポータル――について、CRAが縛るのは供給者であって運用者ではありません。

境界事例は、思い込みではなく法的見解を要します。公開アプリストアで配信されるリテールバンキングアプリ。加盟店に出荷されるホワイトラベル端末。法人顧客に渡す決済SDK。他の加盟国の子会社にライセンス供与するAPIゲートウェイ。いずれも社内サービスというより、商業活動の過程で市場に提供されるソフトウェアに見えます。答えは各行の事情によりますが、問いには期限があります。「範囲外だと想定していました」は、2027年12月に守り抜ける立場ではありません。

SBOMは「あれば良いもの」ではなくなる

附属書Iは、製造者に対し製品に含まれる構成要素の特定と文書化を求め、少なくとも最上位の依存関係を対象とする、広く用いられる機械可読な形式のソフトウェア部品表を作成することを含めています。この条文はゆっくり読む価値があります。機械可読とは、SPDXまたはCycloneDXのことであり、メールに添付された表計算ファイルではありません。SBOMはサポート期間――最低5年、製品の想定寿命がそれより短ければその期間――を通じて最新に保たれ、10年間保管される技術文書の一部を構成します。

議論が始まるのは「少なくとも」という語です。Log4Shellは、被害を受けた資産において最上位の依存関係ではありませんでした。ロギングのファサードの中、フレームワークの中、アプリケーションサーバの中と、三層も四層も下に埋まっていました。直接依存で止まるSBOMは附属書Iの文言を満たしますが、実際に悪用が進行している最中の午前2時に投げかけられる問いには、ほとんど答えません。供給者からSBOMを受け取る銀行は、深さを契約で定めるべきです。規則は下限を定めるだけで、貴行のためにそれを引き上げてはくれません。

二つの時計、一つのインシデント

供給されたコンポーネントに存在する、悪用された一つの脆弱性が、噛み合わない二つの規制上の時計を同時に動かすことがあります。CRA第14条のもとで、製造者は覚知から24時間以内の早期警告、72時間以内のより詳細な通知、そして是正措置が利用可能になってから14日以内の最終報告を負います。提出は一度で、主たる拠点のCSIRTとENISAに宛てられます。DORA第19条と関連する技術基準のもとで、銀行は所管当局に対し、インシデントを重大と分類してから4時間以内かつ覚知から遅くとも24時間以内の初期通知、72時間以内の中間報告、そして最後の中間報告から1か月以内の最終報告を負います。

二つの時計は、起点も宛先も内容も異なり、同一の事象の上を並行して走ります。さらに厄介なことに、銀行の4時間の時計は、しばしばベンダーの開示が届く前に動き出します。金融機関は通常、供給者の通知よりも自らのテレメトリから先に気づくからです。運用モデルの答えは、二つ目の報告チームではありません。二つの出力経路を持つ単一のインシデント記録、DORAの重要性とCRAの該当性を同時に評価するトリアージ工程、そして供給者に対し「彼らの期限」ではなく「貴行の期限」の内側で通知することを義務づける契約上の通知窓です。

供給者の新しい義務は、貴行の交渉力である

CRAが銀行にもたらす最も価値あるものは、これまで供給者の裁量に委ねられていた事柄を、契約可能なものに変える点です。2027年12月以降、適合する製造者は、協調的な脆弱性開示の方針を運用し、最低5年と宣言したサポート期間にわたってセキュリティ更新を提供し、安全な初期設定で製品を出荷し、機械可読なSBOMを引き渡さなければなりません。かつては、力のあるベンダーがあっさり断れる交渉上の要望にすぎませんでした。それが市場参入の条件になりつつあります。

現実的な一手は、ベンダー自身の2027年のスケジュールを引き継ぐのではなく、いま調達に織り込むことです。今四半期に書く価値のある条項としては、指定した深さと形式でのリリースごとのSBOM提供、更新され続ける約束ではなく宣言されたサポート終了日、DORAの4時間と整合する窓の内側での悪用済み脆弱性の通知、そして2027年12月以降に上市される製品についてのCRA適合表明が挙げられます。この作業はDORAの情報登録簿にもそのまま効いてきます。CRAが明るみに出させる供給者の事実は、登録簿がすでに求めている事実とおおむね重なるからです。

書類の背後にあるエンジニアリング

適用範囲の製品を実際に上市する金融機関にとって、コンプライアンス成果物は、寄せ集められたものではなく生成されたものであってはじめて信用に足ります。監査の前週に手作業で作られたSBOMは文書にすぎません。ビルドパイプラインが出力し、署名し、証跡を付し、記述対象の成果物とともに保管されるSBOMは統制です。同じ区別が脆弱性対応にも当てはまります。協調的開示の方針は、受付窓口、トリアージの当番体制、深刻度の判定基準、そして報告されたCVEからリリースされたパッチまでの計測された経路が揃うまでは、PDFのままです。

備えと書類仕事を分けるのは、問い合わせ可能性です。次のLog4Shellが着弾したとき、問いはこうなります。どのリリースが、どの環境で、どの深さであれこのコンポーネントを含んでいるのか。そしてそれを稼働させている顧客は誰か。これに数分で答えるには、バージョンをまたぐSBOMストアと、掲載されたCVEがその製品で実際に悪用可能かを製品ごとに記録するVEXの運用が必要です。VEXがなければ、深いSBOMは主としてノイズを生みます。そしてノイズこそが、24時間という期限を達成不能にするものです。

2027年12月まで15か月

適用範囲の問いに答えが出れば、順序は自ずと決まります。いまから2026年末まで――法務とともに、自行が上市する製品が適用範囲に入るかを確定し、既存のDORAインシデント・トリアージにCRAの該当性判定を組み込み、二つの評価が一度の手続きで済むようにします。2027年前半――調達の雛形を書き直し、重要または重大な機能に最も近いソフトウェアを納める上位10社の供給者にSBOMを要求します。規則がまだ彼らを強制するからではなく、実物のSBOMを10通読むほうが、どんなレディネス評価よりも多くを教えるからです。

2027年後半は、資産全体に及ぶ作業に充てます。綴じ込むのではなく問い合わせるSBOMリポジトリ、自ら出荷する製品のためのVEX、そして適用範囲にあるすべてについての適合証跡です。いずれも風変わりな技術ではなく、その多くはそれ自体として取り組む価値があります。それが早く着手すべき正直な理由です。CRAの期限は、銀行がもともと必要としていた能力を強いる装置にすぎません。すなわち、自らのソフトウェアが実際に何でできているのかを、正確かつ迅速に知る能力です。