Open Source Summit 2021 Japan が2021年12月14～15日にかけてVirtualで開催されました。富士通のセッションでは、ライセンス コンプライアンスに関連してYoctoとmeta-spdxscanner等を組み合わせた組込みシステム向けの開発環境構築について紹介されました。本記事ではそのセッションの概要を紹介します。
なお、スライドは既にSchedにアップロードされていますので、そちらをご参照ください。
Open Source Summit Japan was held in Dec 14-15, 2021 on virtual. There was a Fujitsu's session that about construction of development-system with Yocto and meta-spdxscanner, to solve license compliance issue. This entry describes summary of it session.
ソフトウェア開発における問題とSBOM
組込みシステムを含めたソフトウェア開発は年々大規模化・複雑化していて、1つのプロダクトに取り込むOSSの種類も膨大になってきています。OSSを扱う上で、ライセンスの取り扱いや日々発見される脆弱性などに注意する必要があります。複数のサプライヤーを抱えて開発を行っているようなベンダーでは、サプライヤー各社が取りこんだ大量のOSSを管理する必要があります。その際、使用しているOSSの情報を各社がバラバラなフォーマットで提供していると、受け取る側ではその読み取りや管理する作業が煩雑になるだけでなく、情報の不備により「肝心なライセンス情報が抜けているじゃないか」といったようなことが生じる可能性もあります。
そういったことをなくすために、ソフトウェアに含まれている情報の提示の仕方を取り決める部品表 (SBOM: Software Bill of Materials) を定義しましょう、という取り組みが行われており、いくつかの標準的なSBOM仕様が定義されています。
SWID
SWIDはアメリカ国立標準技術研究所(NIST: National Institute of Standards and Technology) により標準化されたSBOM仕様で、2015年にISOで標準化されました。インストールされたソフトウェアの情報を追跡するために設計されています。XML形式で記述されますが、将来的な仕様改定で記述フォーマットは追加される可能性があります。より軽量なフォーマットであるCoSWIDというものもあります。
参考:
- https://csrc.nist.gov/projects/software-identification-swid/guidelines
- https://www.iso.org/standard/65666.html
CycloneDX
CycloneDXはOWASP (Open Web Application Security Project) によって定義されている仕様です。サプライチェインにてソフトウェアのセキュリティの状況を追跡したりリスク分析するために軽量に設計されたSBOM仕様です。
参考:
SPDX
SPDXはLinux Foundationが策定したSBOM仕様です。2021年にISOで標準化されました。関連するソフトウェア コンポーネント、ライセンス、著作権やセキュリティ情報などを記述できます。SPDXの生成はYoctoでサポートされているため、組込みシステム開発において扱うにはこれが一番簡単です。
参考:
ソフトウェア開発サイクルにおけるセキュリティ問題
ソフトウェアの脆弱性は日々発見されるものなので、製品のリリース後も含まれているOSSに関して脆弱性が報告されていないかなどを追跡する必要があります。そのうえでも統一された仕様によってデータベースで管理できるSBOMが有効です。
また、開発段階においても、取りこんだOSSに対して既に報告されている脆弱性情報の確認、OSSのコード品質確認、In-Houseなソフトウェアの脆弱性の混入などにも気を付ける必要があります。
Yoctoを用いたソリューション例の紹介
SBOMの出力やセキュリティ関連のチェックを開発サイクルの中に組み込むことが重要になります。
セッションでは、SPDX出力のためにYoctoとFOSSologyを連携させる方法、CodeCheckerとの連携によるコードの静的解析の方法やYoctoの機能にあるCVE checkを利用した脆弱性のチェックの方法が紹介されています。
なお、Yocto 3.4 (honister)から、create-spdxクラスがサポートされ、FOSSOlogyなどほかのコンポーネントを使用せずともSPDXの出力が可能になっています。ただし現状は"本当に"最低限のSPDXしか出力されないようです。このセッションではmeta-spdxscannerとFOSSologyを組み合わせたSPDX出力環境の構築方法が解説されています。
FOSSologyとmeta-spdxscanner
PostgreSQLの設定
まず、FOSSOlogyで使用しているPostgreSQLサーバをFOSSologyと別で建てています。これはFOSSologyコンテナからデータを分離しておくためです。
$ docker run --rm -d -p 5432:5432 -u `id -u`:`id -g` ¥
-v /data/workspace/postgres:/var/lib/postgresql/data ¥
-v /etc/passwd:/etc/passwd:ro -e POSTGRES_USER=postgres ¥
-e POSTGRES_PASSWORD=postgres postgres:13.4-buster
PostgreSQLにはFOSSlogy用のデータベースをあらかじめ用意しておきます。
$ psql -h localhost -U postgres
postgres=# create user fossy;
postgres=# ¥password fossy
postgres=# create database fossology;
postgres=# GRANT ALL PRIVILEGES ON DATABASE fossology TO fossy;
Fossologyの設定
FOSSologyのDockerコンテナを立ち上げます。
$ docker run --rm -d -e FOSSOLOGY_DB_HOST="127.0.0.1" \
-p 8002:80 -v /data/workspace/fossology:/srv/fossology \
fossology/fossology:3.11.0
上記によって実行ホストの8002番ポートを使ってFOSSologyサーバが立ち上がります。FOSSOLOGY_DB_HOST=にはPostgreSQLサーバのアドレスを入れますが、スライドの例ではホスト上の5432番ポートをPostgreSQLコンテナにポートフォワーディングしているため、ここではホストアドレスを入れます。
-v /data/workspace/fossology:/srv/fossologyの部分は、FOSSologyで扱うデータをホスト上のディレクトリに置いておくためのものです。こうしておくことで、コンテナを消去してもデータが残ります。
meta-spdxscannerのチェックアウトと設定
meta-spdxscannerはyoctoプロジェクトのサイトからcloneできます。また、OpenEmbeddedのいくつかのレイヤーに依存しているため、それらもまとめて追加します。
$ git clone https://github.com/openembedded/meta-openembedded.git -b hardknott
$ git clone git://git.yoctoproject.org/meta-spdxscanner
source poky/oe-init-build-env buildでビルドディレクトリに移動したら、bitbake-layers add-layerでmeta-spdxscannerと依存レイヤーを追加します。
$ bitbake-layers add-layer ../meta-openembedded/meta-oe
$ bitbake-layers add-layer ../meta-openembedded/meta-python
$ bitbake-layers add-layer ../meta-spdxscanner
FOSSologyと連携するために、Yoctoのlocal.confには下記を記述する必要があります。
INHERIT += "fossology-rest"
FOSSOLOGY_SERVER = "http://127.0.0.1:8002/repo"
FOLDER_NAME = "<フォルダ名>"
TOKEN = "...."
FOLDER_NAMEではFOSSologyに登録されるプロジェクトの名前、TOKENにはFOSSologyから取得したアクセストークンを記載します。
CodeCheckerとmeta-codechecker
CodeCheckerの設定
CodeCheckerもdockerで立ち上げます。
$ docker run –rm -d -p 8001:8001 ¥
-v /data/workspace/codechecker:/workspace ¥
codechecker/codechecker-web:6.17.0
ホストのWebブラウザでhttp://127.0.0.1:8001にアクセスし、"NEW PRODUCT"で新しい名前のプロダクトを作成します。
meta-codecheckerのチェックアウトと設定
meta-codecheckerからCodeCheckerに連携させるために、local.confに設定が必要です。
INHERIT += "codechecker"
CODECHECKER_ENABLED_class-target = "1"
CODECHECKER_ENABLED_pn-clang = "0"
CODECHECKER_REPORT_HTML = "1"
CODECHECKER_REPORT_STORE = "1"
CODECHECKER_REPORT_HOST = "http://127.0.0.1:8001/"
CODECHECKER_REPORT_ENDPOINT = "test0001"
CODECHECKER_REPORT_ENDPOINT = にはCodeCheckerのWeb UIで作成したプロダクト名を入れます。
meta-codecheckerはgithubのJan-Simonさんのプロジェクトからチェックアウトしています。また、meta-clangが必要です。
$ git clone https://github.com/kraj/meta-clang.git -b hardknott
$ git clone https://github.com/dl9pf/meta-codechecker.git
meta-spdxscannerと同様、これらのレイヤーも追加します。
$ bitbake-layers add-layer ../meta-clang
$ bitbake-layers add-layer ../meta-codechecker
CVE check
Yoctoには既知の脆弱性 (CVE: Common Vulnerabilities and Exposures) をチェックする機能があります。local.confに下記を書いてそれを有効にしています。
INHERIT += "cve-check"
参考:
各種結果の確認
CodeCheckerとFOSSologyの結果はそれぞれのWeb UIから確認することができます。
SPDXファイルについてはyoctoビルドディレクトリ下のtmp/deploy/spdx/の下に出力されます。
CVE checkの結果は同じくビルドディレクトリ下のtmp/deploy/cveの下に出力されます。