CERT-In SBOMガイドライン：コンプライアンスを達成する方法

CERT-Inはインドの国家サイバーセキュリティ機関である。そのSBOMガイドラインは、サプライチェーンのセキュリティを強化し、ソフトウェアコンポーネントの可視性を向上させ、脆弱性への迅速かつ標準的な対応を保証することを目的としている。

コンプライアンスは、政府、公共部門、基幹業務、ソフトウェア輸出業者、ソフトウェア・ライフサイクル全般にわたる開発者、インテグレーター、再販業者に適用されます。

OPSWAT SBOMは、CERT-In SBOMデータ・フィールドの自動化と収集を支援し、ソフトウェア・コンポーネントの詳細、透明性とリスク、およびライセンスと使用法に至るまで、主要な領域にわたって可視性と透明性を提供します。

• コンポーネント名：ソフトウェア・コンポーネントまたはライブラリの名前。
• コンポーネントのバージョン：コンポーネントのバージョン番号または識別子。
• コンポーネント・サプライヤー：コンポーネントを提供する事業者（ベンダー、サードパーティ、オープンソース）。
• コンポーネントの起源：コンポーネントの出所（プロプライエタリ、オープンソース、サードパーティ）。
• 一意の識別子：バージョンや所有者を超えてコンポーネントを追跡するための識別コード。
• SBOM データの作成者：SBOM エントリの作成に責任を持つエンティティ。
• タイムスタンプ：SBOM エントリが記録された日時。

• コンポーネントの依存関係：このコンポーネントが依存している他のコンポーネントやライブラリ。
• 脆弱性：そのコンポーネントに関連する既知のセキュリティ問題（深刻度と CVE 参照）。
• パッチのステータス脆弱性に対する現在のアップデートまたはパッチの提供状況。
• チェックサムまたはハッシュ：ファイルの完全性を検証するための暗号値。
• 実行可能プロパティ：コンポーネントが実行可能かどうか。
• Archive プロパティ：コンポーネントがアーカイブファイルとしてパッケージ化されているかどうか。
• リリース日：コンポーネントが最初にリリースされた日付。

CERT-In コンプライアンスの達成は、開発、セキュリティ、運用、およびコンプライアンスの各チーム間の調整を必要とする、段階的な道のりである。各関係者は、ソフトウェアライフサイクルのさまざまな時点で SBOM を作成、維持、共有する役割を果たす。

CERT-In 技術ガイドラインの内容と例を含む以下の表は、SBOM 責任が一般的なソフトウェア構成要素とどのように整合するかを示している：

ソフトウェアインベントリ、脆弱性追跡、およびベンダーが提供する SBOM に関する現在の慣行を特定する。これらを、CERT-In の必須データフィールドおよび形式と照合する。

開発者、IT オペレーション、調達、セキュリティ、およびコンプライアンスチームの役割を明確に定義する。ガバナンスにより、SBOM が一貫して作成、維持され、企業全体で共有されるようにする。

自動化は極めて重要である。ツールは必要だ：

• 新しいリリース、パッチ、アップデートのたびにSBOMを生成する。
• DevOpsパイプライン、ソースリポジトリ、コンテナレジストリと統合する。
• CycloneDXおよびSPDX形式で出力し、規制当局のアライメントに対応

SBOM 生成を SDLC の各段階に組み込む：

• 設計SBOM：計画されたコンポーネント
• ソースSBOM：開発依存関係
• SBOMのビルド：コンパイル中
• 分析対象SBOM：建設後の検査
• デプロイされたSBOM：インストールされた環境
• ランタイムSBOM：アクティブ・コンポーネントの監視

調達契約は、すべてのサプライヤーからのSBOM納入を義務付けるべきである。

SBOMの継続的な更新を確立し、VEX（Vulnerability Exploitability eXchange）やCSAFのような脆弱性アドバイザリーと統合し、暗号化、HTTPS、デジタル署名によって安全な保管と共有を確保する。

セキュリティ戦略にSBOMを活用する方法を知りたいですか？

適切なベンダーやソリューションを選択することは、コンプライアンスと業務効率の両面で極めて重要である。

• SPDXとCycloneDXのサポート
• DevOpsパイプラインおよびCI/CDワークフローとの統合
• 複数のSBOMレベル（設計、ビルド、デプロイ、ランタイム）を生成する能力
• 監査対応レポートと安全な共有メカニズム

適切なパートナーを選択することは、社内の SBOM プロセスを構築することと同様に重要である。CIOと調達リーダーは、RFPとデューデリジェンスのチェックリストの一部として、CERT-Inの整合性を含めるべきである。主な質問は以下の通りである：

• CERT-Inが承認した形式（SPDX、CycloneDX）でSBOMを提供しているか。
• SBOMの更新頻度は、リリース時のみか、継続的か。
• SBOMの生成、検証、安全な共有のために、どのような自動化を提供していますか？
• 安全なSBOM配布（暗号化、RBAC、デジタル署名など）をどのように実施するか。
• 貴社のソリューションは、DevOpsパイプライン、脆弱性データベース、CERT-In勧告と統合されていますか？
• コンプライアンス監査と継続的な規制当局への報告をどのようにサポートしていますか？

このような質問を前もってすることは、ベンダーが書類上のコンプライアンスだけでなく、CERT-Inの進化するガイドラインに沿ったSBOMの実践を持続できることを保証するのに役立ちます。

• 基礎的なワークフローから始め、時間をかけて成熟度を高める
• すべての調達契約においてSBOMの提供を義務付ける
• SBOM 生成を SDLC の早い段階で統合することにより、シフトレフトアプローチを採用する。
• SBOMの認識と規制要件についてスタッフを教育する

組織が表面的に取り組めば、善意の SBOM イニシアチブでさえ失敗する可能性がある。CERT-In は、SBOM は正確で、包括的で、継続的に更新されなければならないと強調している。ここでは、最も一般的な落とし穴のいくつかと、それを回避する方法を紹介する：

完全な SBOM リポジトリを維持し、ガバナンス慣行を文書化し、CERT-In 監査テンプレートと整合させる。

OPSWAT SBOMは、ソースコードやコンテナ内のソフトウェアコンポーネントの正確なインベントリを提供することで、開発者を支援します。開発速度に影響を与えることなく、攻撃者の先を行き、脅威を発見し、脆弱性を検出します。

ソフトウェア開発チームが、オープンソースの依存関係のセキュリティ脆弱性とライセンスに関する懸念を特定し、優先順位を付け、対処できるようにする。

ソフトウェア開発チームが、オープンソースの依存関係のセキュリティ脆弱性とライセンスに関する懸念を特定し、優先順位を付け、対処できるようにする。

コンテナイメージを分析し、パッケージ名、バージョン情報、潜在的な脆弱性の SBOM を生成します。

SBOMコンプライアンスを超えて、高度に進化するソフトウェアサプライチェーン攻撃に対処する。

OPSWAT MetaDefender Software Supply Chainは、サプライチェーンリスクに対する拡張された可視性と強固な防御を提供します。MetaDefenderのゼロトラスト脅威検出・防止技術により、ソフトウェア開発ライフサイクル（SDLC）はマルウェアや脆弱性から保護され、アプリケーションセキュリティとコンプライアンス遵守が強化されます。

30以上のアンチウイルスエンジンを組み合わせることで、検出率を高め、マルウェアがワークステーション、コンテナ、ソースコードに感染するのを効果的に防ぎます。

Proactive DLPTM は、ソースコードに残されたパスワード、シークレット、トークン、API キーなどの機密情報を識別します。

コンテナ・イメージの各レイヤーの下に存在するマルウェア、脆弱性、その他の潜在的リスクを評価し、評価する。

チームがソースコードリポジトリ、コンテナレジストリ、バイナリサービス、またはそれらのツールの組み合わせを使用しているかどうかに関わらず、MetaDefender Software Supply Chain SDLC全体を通して安全性を確保するために、一般的なプラットフォームとのネイティブな統合を提供します。

銀行やNBFCは、SBOMの慣行をRBIのサイバーセキュリティ指令と整合させ、機密データの取り扱いに関する監査要件を厳格化する必要がある。

サプライヤーは、契約の一部として SBOM を提供しなければならない。組織は、透明性とリスク管理のために、内部および外部の SBOM インベントリを維持しなければならない。