開発成果物・OSSの脆弱性リスクを可視化するウェビナーを開催

開発成果物とOSSの脆弱性を理解する

「動いていれば良い」という考え方では、開発成果物やオープンソースソフトウェア（OSS）が持つ潜在的な脆弱性を見過ごす危険性があります。最近注目を集めているのが、欧州サイバーレジリエンス法（EU CRA）です。この法律に対応するため、「ソフトウェア部品表（SBOM）」を提出する必要がありますが、具体的に何を、どのように提出すべきかを理解している企業は少数派です。業界の多くの場面では、「動いているから大丈夫」として成果物を受け入れ、 OSSの更新も何となくCVSS（共通脆弱性評価システム）に基づいて適用しているのが実情です。しかし、一方でIT部門や品質保証などの担当者には、「なぜこのコードが安全なのか」を説明する責任が求められ、それに対悪の体制を整えることが急務とされています。

説明できる開発の重要性

現在の状況では、開発の各プロセスにおいて、どのようにして適正なチェック体制を構築するかが大きな課題です。「ちゃんとやろう」と心がけても、どこから始めればよいのか分からずに足が止まってしまうこともあります。脆弱性の深刻度を単にCVSSスコアだけで判断することはできません。PoCコードの流通や、KEVリストへの掲載状況、信頼できる開発者や元の評価など、さまざまな要素が実際のリスクの優先順位に直結しています。

また、AIが生成するセキュリティのないコードや、インフラストラクチャコード（IaC）に埋め込まれた各種シークレット（APIキーや認証情報）の設定ミスも、脆弱性のもととなることがあります。これらの視点を見逃さないことが必要です。

次年度の体制強化に向けて

「なぜ安心できるのか」、「なぜ改善できると確信できるのか」。これらの問いに対し、現場が適切に回答できる状態を作ることが重要です。次回のウェビナーでは現場の実情を踏まえ、GartnerによるMagic Quadrant評価でもリーダーシップを発揮している「Checkmarx CxOne」ツールを使って、セキュリティレビューと改善、さらにはソフトウェアの透明性と責任追跡性の体制構築について解説します。