こんにちは、NXPチームの皆様、
FlexBuildと組み合わせたLSDK-25.12_DEBIAN-13_LF-6.12.20を使って、i.MX8MP用のDebianベースの製品イメージを構築しています。RED / EN 18031に基づく脆弱性評価および適合性評価をサポートするために、最終出荷画像におけるソフトウェアコンポーネントおよび既知の脆弱性を特定するための繰り返し可能なプロセスを確立する必要があります。
FlexBuild 25.12のソースツリーを調査した結果、以下のことが判明しました。
SBOM-flexbuild.spdx.jsonは、ビルドイメージの内容ではなく、FlexBuildツール自体を説明するパッケージエントリが1つだけ含まれます。
SCR.txt SDK全体のソフトウェアコンテンツレジスタであり、特定のターゲットイメージに実際にインストールされたコンポーネントを表すものではありません。
フレックスビルダーでは、画像固有のSBOMやCVEマニフェスト生成メカニズムを特定できませんでした。
これらの調査結果を踏まえ、以下の点を明確にしていただけますか?
NXPは現在、FlexBuild Debianビルドから画像ごとのSPDX文書のような画像固有のSBOMを生成する公式または推奨の方法を提供していますか?
もしこの能力が計画されている場合、目標のリリースや予想される稼働状況を教えていただけますか?
NXPは現在、Debian Linux SDKs / FlexBuild向けにVigiles統合を提供している、または提供する予定がありますか?これはYoctoで利用可能なmeta-timesysワークフローに相当します。
直接統合が利用できない場合、Vigiles FAQに記載されているように、CSVマニフェストを手動で作成してインポートする方法は、FlexBuildベースのイメージに対して依然として推奨されるアプローチですか?
このリリースに含まれる以下のコンポーネントのセキュリティアドバイザリー、CVE適用情報、セキュリティ修正の公式情報源は何ですか?
Linux-IMX LF-6.12.20-2.0.0
uboot-imx lf-6.12.20-2.0.0
imx-atf
imx-optee-os
NXPが提供するファームウェアおよびDDR、HDMI、VPU、ワイヤレスファームウェアなどのバイナリパッケージ
例えば、NXPのセキュリティアドバイザリー、リリースノートの修正済みCVEリスト、特定の維持管理されているGitブランチ、あるいは他の公式ソースに頼るべきでしょうか?
LSDK-25.12および関連するlf-6.12.20 BSPコンポーネントの保守およびセキュリティ更新のライフサイクルはどのようなものですか?
特に:
このリリースのセキュリティ修正はどのくらいの期間提供されますか?
バックポートされた修正を監視するために、どのブランチまたはリポジトリを監視すべきでしょうか?
NXPは、継続的な脆弱性マネジメントプロセスを必要とする製品に対してどのようなアップグレード頻度を推奨していますか?
私たちの目標は、実際の出荷イメージに対して、再現性があり、証拠に基づいたSBOMおよびCVE評価プロセスを確立することです。公式ドキュメント、サポートツール、推奨手順の参考文献があればぜひ教えていただけると助かります。
よろしくお願いします。
こんにちは、 @Chavira さん。
Debianディストリビューションのサポート状況についてのご説明ありがとうございます。
Debianとの統合自体は、概念実証として提供されていることを理解しています。しかし、残された疑問は基盤となるBSPコンポーネントに関するものであり、私たちが知る限り、Yocto BSPリリースで消費されているリポジトリやブランチと同じです。
- Linux-IMX(LF-6.12.20-2.0.0)
- uboot-IMX(LF-6.12.20-2.0.0)
- IMX-ATF
- IMX-optee-OS
- NXP提供のファームウェアバイナリ(DDR、HDMI、VPU、ワイヤレス)
どのビルドシステムやルートファイルシステムが使われているかに関わらず、確認していただけますか:
1. これらのコンポーネントのセキュリティ修正はlf-*リリースブランチを通じて提供されるのか、またYocto BSPリリースノートに公開されている修正CVE情報は、これらのコンポーネントのCVE修復状況の権威ある情報源なのか?
2. lf-6.12.20世代に関して、これらのコンポーネントに適用されるセキュリティ修正を得るために、どの後続のlf-*リリースやブランチを監視すべきか?
3. lf-6.12.20 BSPコンポーネント生成のメンテナンス期間はどのくらいで、継続的な脆弱性マネジメントプロセスを維持する必要がある製品に対してNXPはどのアップグレードの頻度を推奨していますか? [[ ## completed ##]]
私たちはNXPにDebianベースのイメージのサポートや検証を求めているわけではありません。NXP BSPコンポーネント自体の公式なセキュリティ修正情報源を特定するSO、それをCAN追跡・適用できます。
よろしくお願いします。
こんにちは、 @Leo_dev さん。
NXPサポートまでご連絡いただきありがとうございます。
残念ながら、DebianはNXPによって概念実証ディストリビューションと見なされており、YoctoベースのBSPリリースと同じレベルのサポート、検証、長期的なメンテナンスを受けていません。
実際、起動時には、ソフトウェアが機能やサポートの保証なしに提供されていることを示す免責事項が表示されます。その結果、Debian上で直面する問題は、Yoctoベースのイメージで再現される問題と同じレベルの調査や検証を受けられない場合があります。
本番開発や完全にサポートされたユースケースには、NXPが提供するYocto BSPの使用を推奨します。
私たちの公開されているすべてのソースコードはGitHub上でホストされており、以下の組織を通じてアクセスCANです。
よろしくお願いします、
チャビラ
こんにちは、 @Leo_dev さん。
1. はい。NXP BSPコンポーネントのセキュリティ修正は通常、公式のlf-releaseブランチを通じて提供されます。i.MX Linux BSPリリースノート(RN00210)および関連するマニフェスト/変更ログは、統合修正やCVE修復状況の追跡における主要なNXP参照資料です
2. LF6.12.20世代については、LF6.12.34_2.1.0などの後続のBSPリリースを監視します。LF6.12.49_2.2.0、LF6.18.2_1.0.0、およびそれ以降のリリースでは、セキュリティや保守の修正がこれらのブランチに引き継がれます。
3.継続的な脆弱性管理が必要な製品に対して、NXPの推奨方法は、新しいBSPのメンテナンスや四半期ごとのリリースを定期的に追跡・評価し、セキュリティアップデートやバグ修正を取得することです