CRAの要求を満たすSBOMは「ソフトウェアBOM」ではなく「セキュアBOM」【第3回】

　従来の製造物責任法（PL法）では、セキュリティ対策が十分でなくても、結果としてセキュリティインシデントさえ発生しなければ罰せられることはなかった。そのため、セキュリティ対策よりコストや納期を優先するメーカーが少なくなかった。CRA（EU Cyber Resilience Act：欧州サイバーレジリエンス法）は、そのPL法の欠点をカーバーする。結果だけでなく、十分なセキュリティ対策の取り組みをメーカーに要求する。

　具体的には、CRAはメーカーに対して、企画・開発段階でセキュリティのリスク分析を網羅的に実施し、許容できないセキュリティリスクに対して妥当性のあるセキュリティ対策を講じることを要求。さらに出荷後、セキュリティ対策が危殆化した、またコンポーネントに脆弱性が発見された場合には遅滞のない修復を求める。

　従って、セキュリティ対策よりコストや納期を優先することは許されない。セキュリティの検討や対策が不十分なまま製品を出荷すれば、たとえセキュリティインシデントが発生していなくても、今後はCRAで罰せられることになる。

　ではCRAの要求通りに、妥当性のあるセキュリティ対策を講じたことを、どのように証明すれば良いだろうか。セキュリティ対策が危殆化した、あるいはコンポーネントに脆弱性が発見された場合に、遅滞なく修復するには、どのような仕掛けが必要だろうか。この証明と仕掛けを担うのが筆者らが提言する「セキュアBOM」である。

　セキュアBOMは、セキュリティ対策の一覧表だ。セキュアBOMがあれば、EU（European Union：欧州連合）当局やユーザーなどの第三者も妥当性をチェックでき、メーカーは妥当性のあるセキュリティ対策を講じたことを、EU当局を含む第三者証明しやすくなる。

　またセキュアBOMが作成できていれば、出荷後にセキュリティ対策が危殆化する、または新たな脆弱性が発見された場合に「どの製品が影響を受けるのか」「どこを修復すれば良いか」が素早く分かるようになり、遅滞のない修復が可能になる。

　一般に「SBOM」といえば「ソフトウェアBOM」のことである。OSS（Open Source Software）ライブラリーや商用コンポーネント、ファームウェアなど製品に関わるソフトウェアを網羅的に管理する一覧表だ。しかしソフトウェアBOMだけでCRAに対応しようとすると、運用に膨大なコストとリソースが必要になるだけでなく、ハードウェア対策部分が抜けてCRA違反に問われる可能性も高くなる。

　インシデント発生時も、その膨大なリストから関連モジュールを特定するだけで時間がかかり、迅速な初動対応が妨げられる。仮に対象を特定できたとしても、そこから修正や回避策といった具体的な対処に直結しにくい点も課題だ。結果として、CRAが求める迅速な報告や対応を十分に果たせなくなる恐れがある。

セキュアBOMの本質は“説明責任を果たす”こと

　にもかかわず「ソフトウェアBOMさえ作ればCRA対応は万全だ」という風潮があることは見逃せない。なぜ、そのような風潮が生まれるのだろうか。そこには、いくつかの勘違いがある（図1）。

図1：CRA対応における“よくある”勘違いの例