ソフトウェア部品表（SBOM）でサプライチェーンのリスクを低減

ソフトウェアサプライチェーンセキュリティソリューションの継続的な強化に向け、本日、新機能をいくつかリリースしました。Software Supply Chain Securityこの開発者を第一に考えたツールを使えば、アプリのサプライチェーンをより深く把握し、潜在的なリスクを特定して、先手を打つために必要な対応を取ることができます。

サプライチェーンセキュリティの要として広がるSBOM

現代のアプリケーションは一から開発するというより、さまざまな要素を組み合わせて作られています。現代のソフトウェアの70%超を、フリーおよびオープンソースソフトウェアが占めています。アプリにオープンソースを活用すれば市場投入までの時間を短縮できますが、サプライチェーンに複雑さやリスクが生じる可能性もあります。

組織の保護を目的とした最近の規制ガイダンスを受け、多くのチームがSDLCにソフトウェア部品表（SBOM）の作成を取り入れています。

おさらいすると、SBOMとは、アプリケーションを構成するコンポーネントとその依存関係を一覧にしたものです。製造業で使われる「部品表」と同じように、製品に使われている部品を購入者に伝えるものと考えるとよいでしょう。CycloneDXやSPDXなどの標準化されたSBOM形式を使えば、人が読みやすく、後続のツールでも利用できる一覧を作成できます。

AppSecチームにとって、企業全体で構成を可視化することは、規制要件を遵守しながらサプライチェーン攻撃のリスクを理解し、軽減するための重要な一歩です。

では、こうしたプラクティスをどう取り入れればよいのでしょうか。また、開発者のワークフローにはどのような影響があるのでしょうか。

これまで、セキュリティ態勢の強化によって開発チームの速度が落ちることもありました。しかし、開発者がイノベーションとセキュリティのどちらかを選ばなければならない状況は避けるべきだと、私たちは強く考えています。SnykならアプリケーションのSBOMを簡単に作成でき、オープンソースのコンポーネント、ライブラリ、フレームワークなど、アプリを構成する要素と、それらがどのように連携しているかを可視化できます。

一般提供を開始したSnykの開発者向けCLIツールを使えば、ローカル環境またはCI/CDパイプラインから、SPDX形式またはCycloneDX形式のSBOMを生成できます。

snyk sbom --format spdx2.3+json --all-projects

同じく一般提供を開始したProject SBOM APIを使えば、SnykにインポートしたオープンソースプロジェクトやコンテナプロジェクトのSBOMを、単一のAPIエンドポイントから生成できます。

SBOM内のパッケージの例

1{
2"bom-ref": "35-curl@7.52.1-5",
3"type": "library",
4"name": "curl",
5"version": "7.52.1-5",
6"purl": "pkg:deb/debian/curl@7.52.1-5?distro=stretch"
7}

SBOMを使ってリスクを特定し、対処する

SBOMの生成は、可視性を高め、規制要件を遵守するための重要な一歩ですが、それだけでは十分ではありません。SBOMの成果物だけでは、後続の利用者が実際に行動に移せる情報が得られないことも少なくありません。

開発者やAppSecの専門家は、潜在的な問題を特定し、迅速に対処するために、SBOMとその内容を検査する必要があります。組織でSBOMの生成が広がり、サプライヤー（SaaSなど）からSBOMを受け取るようになると、さまざまなツールが出力する複数の形式を検査する必要も出てくるでしょう。

企業内のすべてのチームでこれを管理するためのプラットフォームを構築したいと考えるかもしれません。

第3四半期初頭に、SBOM検査機能のベータ版をリリースする予定です。このAPIを使えば、当社の業界有数の脆弱性データベースをもとに、CycloneDXおよびSPDX形式のSBOMをスキャンし、既知の脆弱性やライセンスの問題を検査できます。

また、一般提供を開始したPackage Issues APIを使えば、パッケージURL（purl）をもとにパッケージ単位で脆弱性を検索できます。さまざまなプログラミング言語やオペレーティングシステムのエコシステムに対応しています。きめ細かな低レベルAPIにより、チームはニーズに合わせて柔軟に検査をカスタマイズできます。

パッケージの問題を取得する例

GETリクエストとURLエンコードしたpurlを使って、単一のパッケージを検索できます。

https://api.snyk.io/rest/orgs/{{orgId}}/packages/pkg%3Adeb%2Fdebian%2Fcurl%407.52.1-5%3Fdistro%3Dstretch/issues?version=2023-05-10

返される脆弱性の例（一部省略）

1...
2"id": "SNYK-DEBIAN9-CURL-2936242",
3"type": "issue",
4"attributes": {
5"key": "SNYK-DEBIAN9-CURL-2936242",
6"title": "Out-of-bounds Write",
7"type": "package_vulnerability",
8"created_at": "2022-06-28T02:25:54.487787Z",
9"updated_at": "2023-02-14T13:32:10.421029Z",
10"description": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `curl` package and not the `curl` package as distributed by `Debian:9`._\n_See `How to fix?` for `Debian:9` relevant fixed versions and status._\n\nWhen curl < 7.84.0 does FTP transfers secured by krb5, it handles message verification failures wrongly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed 
11...

SBOMの価値をさらに高める

アプリケーションの構成を把握すること自体に価値がありますが、SBOMの成果物だけでは通常、含まれる情報が限られています。

脆弱性検査の入力情報としては十分でも、改善の余地は大きく残されています。成果物を受け取った側は、必要な知見を得るためにSBOMを使って調査しなければなりません。

SBOMを作成し、コンポーネントとともに検査できるのなら、最初からその情報を成果物に含められないでしょうか。Snykがオープンソースコミュニティに新たに提供するParlayは、まさにこの課題の解決を目指しています。

主要な形式であるCycloneDXとSPDXは、すでにスキーマの拡張に対応しています。これにより、脆弱性やソースの来歴などのメタデータを追加して、SBOMを充実させることができます。

これにより、AppSecチームなどの後続の利用者は、アプリケーションのある時点でのスナップショットに加え、アクションの自動化や意思決定に役立つ豊富なデータを受け取れます。

このプロジェクトで実現することについて、詳しくはこちらのブログをご覧ください。また、SnykLaunchで見逃した内容は、オンデマンド録画でご確認ください。