tech.guitarrapc.cóm

Technical updates

トップ > C# > OSS開発者にとってのSBOMとSLSAの状況
最終更新日

OSS開発者にとってのSBOMとSLSAの状況

C#

ソフトウェアのサプライチェインを担保する手段としてSBOMとSLSAがあります。 SBOM（Software Bill of Materials）は、そのソフトウェアの構成要素をリスト化したもの、SLSA（Supply chain Levels for Software Artifacts）は、ソフトウェア成果物の工程がどの程度信頼できるかを段階的に定義したフレームワークです。

今回は、2026年1月時点におけるSBOMとSLSAの状況について調べたことのメモです。

モチベーション

ここ数年OSSソフトウェアを利用した攻撃の1つとしてサプライチェイン攻撃を見かける頻度が上がっています。攻撃の最終目標は仮想通貨プラットフォームへの侵入だったりするようですが、OSSソフトウェアは他のOSSソフトウェアに依存していることが多いという性質から、攻撃者はその依存関係を悪用して攻撃を仕掛けることができます。

OSSライブラリ作者として自分が開発しているOSSライブラリがサプライチェイン攻撃に巻き込まれた際、その影響を早く確認し、また利用者に正当なライブラリであることを証明するのに役立つのがSBOMとSLSAです。これらを組み合わせることで、そもそもライブラリに影響しているのか確認しやすくし、またライブラリ利用者が正当なライブラリか検証しやすくなります。

今回の調査は、今後OSSライブラリ回りでSBOMやSLSAが要請されるようになる可能性もあるため、それに備えて現状のSBOMとSLSAの状況を調べておくのを動機としています。この調査を元に、次回はC#ライブラリにおけるSBOMとSLSAについてみていきます。

サプライチェインとSBOMとSLSA

ソフトウェアのサプライチェインは2つの視点があります。SBOMとSLSAはそれぞれ別領域で、サプライチェインという視点では両者が揃うことで、ソフトウェアの信頼性を高めることができます。

  1. そのソフトウェアは何でできているのか。構成しているソフトウェアは何なのか部品を明確にする -> SBOM
  2. そのソフトウェアがどのように作られたか（provenance）を、アテステーションなど検証可能な形で示す -> SLSA

つまりSBOMで何が入っているかをリストアップし、ハッシュで改ざんされてないか、SLSAのアテステーションで「そのハッシュが正規のビルド工程から生成されたという主張」を署名付きで提供するイメージです。これを提供したいかどうかが判断基準になります。

SBOMの例としてSPDX2.2フォーマットの一例を見てみましょう。filesに配布時含まれるファイル群、packagesにソフトウェアを構成するパッケージ群が記載されます。NOASSERTIONはSBOM発行時に指定しないなどの理由で情報がない場合に使われます。なるほど、確かにSBOMを見れば、そのソフトウェアが何でできているのか把握できます。

{
  // 含まれるファイル群
  "files": [
    {
      "fileName": "./lib/libfoo.so",
      "SPDXID": "SPDXRef-File--lib-Example.libfoo-AAAAAAA",
      "checksums": [
        {
          "algorithm": "SHA256",
          "checksumValue": "ハッシュ値"
        },
        {
          "algorithm": "SHA1",
          "checksumValue": "ハッシュ値"
        }
      ],
      "licenseConcluded": "NOASSERTION",
      "licenseInfoInFiles": [
        "NOASSERTION"
      ],
      "copyrightText": "NOASSERTION"
    }
  ],
  // 構成するパッケージ群
  "packages": [
    {
      "name": "Example.Package",
      "SPDXID": "SPDXRef-Package-Example.Package",
      "downloadLocation": "NOASSERTION",
      "filesAnalyzed": false,
      "licenseConcluded": "NOASSERTION",
      "licenseDeclared": "NOASSERTION",
      "copyrightText": "NOASSERTION",
      "versionInfo": "1.0.0",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:foo/Example.Package@1.0.0"
        }
      ],
      "supplier": "NOASSERTION"
    },
  ],
  "externalDocumentRefs": [],
  "relationships": [],
  // SBOMドキュメント情報
  "spdxVersion": "SPDX-2.2",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-project-1.0.0",
  "documentNamespace": "http://spdx.org/spdxdocs/example-project-1.0.0-12345678",
  // SBOM作成情報
  "creationInfo": {
    "created": "2026-01-16T12:00:00Z",
    "creators": [
      "Organization: ExampleOrg",
      "Tool: ExampleSBOMGenerator-1.0"
    ]
  },
  "documentDescribes": []
}

SLSAの例としてGitHub Actionsのアテステーションレポートを見てみましょう。ジョブでアテステーションレポートをid-token署名付きで生成、アテステーション一覧からたどることができます。ここには、いつ(日付)、だれが(実行者)、どこで(GitHubホステッド環境)、どのように(どの時点のどのワークフロー)そのソフトウェアを生成したかが記載されます。たしかにこれがあれば、そのソフトウェアがGitHub Actionsで生成されたことがわかります。

SLSAの例

SBOMで構成要素を把握し、SLSAでその生成プロセスを保証することで、ソフトウェアの信頼性を高めることができるという考え方とわかります。

OSSライブラリ開発者にとってのメリット

OSSライブラリの開発者としては、自身のOSSライブラリの構成を把握し、配布物が外部から検証可能な形で提供できることに一定のメリットがあります。

  1. SBOMがあれば、サプライチェイン攻撃に巻き込まれたとき、いつの時点のライブラリが影響を受けたのか特定しやすくなる
  2. SLSAがあれば、自身のライブラリが正当に生成されたものであることを示せる

サプライチェイン攻撃が発生したときにSBOMを確認することで、いつの時点のライブラリが影響を受けたのか特定しやすくなります。また、SBOM発行時の設定次第では、構成するライブラリにMPLやGPLライセンスなど自身が意図しないライセンスのライブラリが含まれているか確認できます。

SLSAはソフトウェアのサプライチェインのセキュリティレベルを評価するフレームワークで、レベル1(低)からレベル4(高)まであります。SLSAレベルが高いほどソフトウェアが改ざんされていないことを外部から検証しやすくなります。従来からSHA256などハッシュ値による検証はありましたが、そのハッシュ値が正当に生成されたものであるかまでは検証できません。それに対してSLSAは、例えばGitHub Actionsでビルドしてリリースしている場合に、ソフトウェアが生成されたから配布されるまでのプロセスとセットにすることで、ただのハッシュ値検証よりも強力にパッケージの正当性を保証します。

もう少し詳しくSBOMとSLSAについて見ていきましょう。

SBOM

SBOMは、そのソフトウェア(あるいはコンテナイメージ)に含まれる依存関係を、機械可読な形で列挙するものです。SBOMのフォーマットとしてSPDXとCycloneDXがよく使われますが、いずれにしてもSBOMには次の情報が記載されます。

  • 使われているライブラリとそのバージョン
  • 直接依存・間接依存の区別
  • ライセンス情報
  • ハッシュ

SBOMには、Source SBOMとBuild SBOMの2種類があります。Source SBOMは、ソースコードの依存関係から生成されるSBOMで、例えばロックファイル(packages.lock.json)から生成されます。一方、Build SBOMは、ビルド成果物から生成されるSBOMで、実際に含まれているライブラリを正確に反映します。

ただし、SBOMはSBOMファイルが正しいかは保証せず、改ざんされた場合もSBOM自体では判別できず、誰が作成したかの保証もできません。それって困りますよね？ ということで、成果物がどうやって生成されたかを保証するSLSAが補完的に欲しくなります。

SBOMの生成ツール

OSSなら、microsoft/sbom-toolとanchore/syftがよく利用されています。両方ともCLIツールを提供していますが、sbom-toolは.NET向けのMSBuildタスクがありNuGetパッケージ作成時に自動的に含めることができます。

また、GitHubもリポジトリ > Insights > Dependency graph > Generate SBOMからSBOMを生成できます。Export SBOMしたことはなくても、Dependency graphページをみたことがある人は多いんじゃないでしょうか。

SBOMをエキスポート

SBOMのフォーマット

SBOMのフォーマットとしてSPDXとCycloneDXがよく使われます。SPDXはLinux Foundationが策定したフォーマットで、オープンソースソフトウェアのライセンス情報を管理するために設計されました。一方、CycloneDXはOWASPが策定したフォーマットで、セキュリティに重点を置いています。どちらも広く使われていますが、SPDXはライセンス情報に強みがあり、CycloneDXはセキュリティ情報に強みがあります。

CycloneDXは脆弱性情報やVEXなどセキュリティ用途の拡張が充実しており、開発中のソフトウェアのSBOM生成に向いています。一方、SPDXはライセンス情報に強みがあり、配布物に同梱するSBOMとして向いています。どっちかのフォーマットに統一するという感じではないようです。OSSライブラリ開発者としては、配布物にSBOMを同梱する場合はSPDXを選ぶとよいでしょう。

なお、SPDXにはバージョン2.2/2.3と3.0がありますが、現時点では2.2/2.3対応ツールが主流なため3.0に手を出すのはまだ早い印象です。3.0はデータモデルが刷新されており、2.xの文書を3.0として扱うには変換が必要です。

SBOMの課題

使っていて感じた課題がいくつかあります。

  • ツールによって生成結果が異なる
  • 生成時に指定しなかった情報はNOASSERTIONになる
  • SPDX v3.0はいつから使えるのか

SBOMはフォーマットがあるにも関わらず、ツールによって生成結果が微妙に異なっており一貫したフォーマット提供に課題があります。ツールによって含まれるコンポーネント数が違うのはしょうがないとしても、依存階層が一致しないとか困ったものです。

また、SBOM生成時にライセンスなどを指定しない限りはNOASSERTIONになります。このため、必要な情報を含めるにはどうすればいいのかはツールごとに調べる必要があります。ライセンス情報はSigstoreなどから収集することが多いようなので、ライブラリやツールのバージョン途中からライセンス変わったらどうなるの?新しいバージョンでライセンス変わった時に反映はいつ?など気になる点があります。

SPDX v3.0は2024年にリリースされましたが、一年たっても試験対応ポジションのツールが多いのも気になります。SBOMツールには外部からのコントリビュートは明示的に拒否するポリシーをもつケースもあることから、セキュリティに関わるので時間がかかっても安定したフォーマット出力を優先する気配は感じます。

SLSA

SLSAは、その成果物が信頼できる工程で作られたことを段階的に保障することを目的としたフレームワークです。SLSA v1.0には4つのレベルがあり、レベルが上がるほど信頼性が高くなります。

  • Level 1: ビルド来歴(Provenance)がある
  • Level 2: ビルド来歴(Provenance)が署名されており、ホステッドビルド環境で生成されている
  • Level 3: 改ざんに強いビルド基盤
  • Level 4: 再現可能・検証可能

GitHub Actionsを使うことで、ビルド来歴提供やビルド自動化が実現できるのでSLSAレベル1と2は比較的簡単に達成できます。Provenanceを具体化したものが、先のアテステーションレポートでありレベル2の提供です。レベル3にはビルド基盤が改ざんしにくくなる工夫を要します。GitHubでのSLSA対応はドキュメントが用意されているので参考になります。

ただ、アテステーションレポートがあるかといってソフトウェアが安全である保障はないことには注意が必要です。SLSAでソフトウェアのソースコードとビルド手順へのリンクは提供されますが、ソフトウェア自体のリスク判断は行いません。例えば、悪意のあるコードがソースコードに含まれている場合、そのソースコードをビルドした成果物はSLSAレベル4であっても安全とは言えません。

SLSAの検証ツール

SLSAアテステーションレポートを検証するツールとして、ghコマンドやslsa-verifierがあります。GitHub Actionsを使っているなら、ghコマンドを用いるのが簡単です。

# Verify an artifact linked with a repository
$ gh attestation verify example.bin --repo github/example

# Verify an OCI image using attestations stored on disk
$ gh attestation verify oci://<image-uri> --owner github --bundle sha256:foo.jsonl

# Verify an artifact signed with a reusable workflow
$ gh attestation verify example.bin --owner github --signer-repo actions/example

slsa-verifierでもGitHubアテステーションレポートは検証できます。

$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/MODULE.bazel
$ curl -sSO https://bcr.bazel.build/modules/aspect_rules_lint/1.3.4/MODULE.bazel.intoto.jsonl
$ slsa-verifier verify-github-attestation --source-uri github.com/aspect-build/rules_lint --builder-id https://github.com/bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml --attestation-path MODULE.bazel.intoto.jsonl MODULE.bazel

SLSAレベル3は現実的なのか

SLSAレベル3の改ざんに強いビルド基盤とは、誰も変更できないことを意味するのではなく、変更された場合にその事実を後から検証できる、という意味である点には注意が必要です。言い換えると、「そのビルド成果物が事前に定義されたビルド手順から人の手による介入なく生成されたものであることを後から検証できる」ことを意味します。

SLSAレベル2以上はホスト環境を求めていますが、これはビルド環境の完全性をGitHubなどクラウド事業者の責任範囲において、代わりにユーザーが直接触れないことを信頼の根拠にしていると捉えられます。GitHub ActionsのホステッドランナーはMicrosoftが管理しており、ユーザーはその環境に直接アクセスできません。つまり、ビルド環境の完全性をMicrosoftに依存することで、ユーザーはビルド環境が改ざんされていないことを信頼できます。

誤解していたこと

改ざんに強いは「ビルドステップ自体を改ざんできない」という意味ではないことは注意が必要です。私はこれを当初誤解していました。GitHub ActionsでSLSA3を達成するためのドキュメントが提供されています。これはビルドにReusable Workflowを使うことを求めていますが、ビルドステップを別リポジトリで管理するのが直接的にビルド自体が改ざんできなくなるかというと、個人的には疑問があります。そのリポジトリがプライベートリポジトリである場合、「ビルドステップは外部から改ざんするのは非常に困難である」と言えそうですが、パブリックリポジトリである場合、誰でもプルリクエストを送れるためマージ・レビュー次第では「ビルドステップが改ざんに強いであるとは言い切れない」です。改ざんに強いはあくまでも外部からのPRを受け付けない、内部の変更に対しても注意を払うしかないということになります。

実際にできそうなライン

GitHubドキュメントを見る限り、OSSライブラリ開発者としてSLSAレベル3を達成する以下の条件を満たすのは現実的なラインと考えています。

  • ビルドステップをReusable Workflowで管理する
  • アテステーションレポートを生成する

GitHub Actionsでアテステーションを生成するのは、ジョブに権限をつけて1つステップを追加するだけで済みます。これを丸っとReusable Workflowにしておくイメージです。

on:
  # Reusable Workflowとして呼び出される
  workflow_call:

jobs:
  build:
    # 権限が必要
    permissions:
      attestations: write
      contents: read
      id-token: write
    runs-on: ubuntu-24.04
    steps:
      # ...ビルドステップで成果物を生成する
      - name: Build lib...
        run: ...

      # アテステーションを生成すると、自動的にGitHubに登録される
      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@977bb373ede98d70efdf65b84cb5f73e068dcc2a # v3.0.0
        with:
          subject-path: "./publish/libfoo.so"

しかし、Reusable Workflowに分けても、それを改ざんされたら意味がないのでなんだかちぐはぐ感は否めない気もします。

改ざんとイミュータブルリリース

改ざんについて考えると、同一リリースやタグを上書き可能な場合、後から改ざんしてアテステーションを差し替える余地があるように思えます。例えば、GitHub Releasesで同一タグを上書きできる設定になっている場合、ビルド工程を丸っと乗っ取られた場合に、同じタグやリリースを後から上書きされる可能性があります。権限次第でアテステーションも削除ができますしね。これを仕組みで防ぐには、イミュータブルリリースが必要になります。

幸いGitHubはImmutable Releasesをサポートしているので、これを有効にすることで同一タグの上書きを防ぐことができます。SLSAうんぬんに関わらず、この設定は有効にしておくのがよさそうです。

SBOMとSLSAの活用例

SBOMとSLSAを使った活用例はいくつか見かけるので紹介します。

SBOMをライセンスリスク管理に使う

SBOMでライセンス情報も出力することで、ライセンスリスク管理が可能になります。例えば、MITで配布したいライブラリに、GPLライセンスや商用ライセンスが混入することは避けたいでしょう。しかし、ライブラリの依存関係が複雑になると、どのライブラリがどのライセンスなのか把握するのは困難です。SBOMを使うことで、ライセンス情報を自動的に収集し、ライセンスリスクを管理できます。

SLSAをアーティファクトのハッシュ値検証に使う

SLSAアテステーションが発行されていると、単にハッシュ値を配布するだけでなく「ハッシュが何のか + そのハッシュがどの工程で生成されたか」まで含めて検証できるようになります。よくリリースアーティファクトにlibfoo.soとlibfoo.so.sha256のように提供されているハッシュ値は、ダウンロード途中で改ざんされた際に改ざんを検出できるものの、そのハッシュ値自体が改ざんされていた場合には検出できません。つまり、攻撃者がlibfoo.soとlibfoo.so.sha256の両方を改ざんした場合、利用者がそれを検出できる仕組みではありません。

SLSAアテステーションレポートには、対象アーティファクトのハッシュ値が含まれ、利用者はそのビルドステップで生成されたものであることを検証できます。

例えば、aquaがこれを使ってインストールするパッケージの改ざんチェックを行っています。

まとめ

個人的に調べたSBOMとSLSAの状況についてのメモ書きでした。

OSSライブラリ開発者としては、SBOMを配布物に同梱することは悪くなさそうです。ただGitHubのInsightsから見てもらったり、Dependabotに任せることができている現状からすると、SBOMを積極的に活用する場面はまだ少ない印象です。標準ビルドで自動的に生成されるなら、配布パッケージに入れても損はないかなという温度感。

SLSAに関しては、GitHub Actionsを使っている場合はアテステーションレポートを生成するのは簡単なので、OSSライブラリの信頼性を高めるために導入自体は悪くなさそうです。GitHub Actionsを利用しているOSSライブラリ開発者としては、SLSAレベル3 + アテステーションレポートを添えるのは難しくない感触です。

SBOM/SLSAに関わらず、リリースが後から上書きされるのは利用者からすると疑いしかないので、SBOM/SLSAに関わらずGitHubのイミュータブルリリースは有効にしておくのがよさそうです。

参考

GitHub

規格

ドキュメント

ブログ