Githubのサプライチェーン攻撃に対する取り組み

unknown protocol

MicrosoftがSBOMを生成するツールを発表したが、その背景には「サプライチェーン攻撃」があるらしい。

サプライチェーン攻撃に関してはMicrosoft以外も取り組んでいて、そのうちのひとつであるGithubのブログを読んでみる。

Supply chain security has been top-of-mind in light of recent software security incidents, including the Log4j vulnerability and the Solarwinds attack in 2021.

2021年のLog4jやSolarwindsの事例が「サプライチェーン攻撃」をtop-of-mindに押し上げたという。

では、どういうことをしたのか。ちょっと長いので分けて書く。

Last year, we announced that our default container publishing workflow would now generate signed images. Today, we’re applying that same method to Go projects. We’re also going a step further by adding support for automatically generating non-forgeable build provenance with GitHub Actions and Sigstore’s signing tools using a new GitHub workflow.

箇条書きにすると

  • コンテナをpublishする際に、デフォルトで署名されたイメージが生成されるようにした（昨年に発表）

  • 同じ方法をgoのプロジェクトにも適用した

  • Github ActionsやSigstoreでnon-forgeable build provenance（ビルドの履歴を偽造できないようにする機能）を自動生成できるようにした

ということになる。

ちなみにSigstoreというのはコードに署名するための仕組みでLinux FoundationやGoogleなどがコミュニティに参加している。下の画像はSigstoreがどのように動作するかを示した画像だ。

https://www.sigstore.dev/how-it-works

さて、元のGithubのブログに戻る。

This allows users to not only verify that the software they receive is authentic, but also to verify where it was built and with which software. This meets a new compliance standard from the OpenSSF called SLSA 3, which aims to help organizations improve their security posture against supply chain attacks. This workflow is available in the Actions tab in any GitHub repository.

こうすることで本物(authentic)かどうかを検証(verify)するだけでなく、どこでビルドされたのかも検証できるようになる。

で、これはOpenSSF(Open Source Securiry Foundation)が策定しているSLSA3という基準に適合する。

Supply chain Levels for Software Artifacts, or SLSA (salsa). It’s a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises. It’s how you get from safe enough to being as resilient as possible, at any link in the chain.

SLSA(salsaとも呼ぶ？)は直訳すると「ソフトウェアのためのサプライチェーンレベル」で、tampering（改ざん）を防ぎ、integrity（完全性）を高め、パッケージやインフラを安全にするためのチェックリストであり、フレームワークというわけだ。

で、Githubが「SLSA 3になったよ」と言ってるのは、上の表のLevel3ということになる。

The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination.

より詳細にはソースとビルドプラットフォームについて履歴をauditability（監査できること）を求めている。cross-buildのcontamination（汚染）のようなケースを想定しているようだ。

余談だがSLSAにはLevel 4というものもある。

The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively. We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross-build contamination.

ざっくり訳すと「2人でやれば安全だよね」ということらしい。ちょっと二度見してしまった。このドキュメント、Version 0.1なのだが、ずっとこのままだろうか。

どの企業も自分で安全だと主張するだけでなく、安全性のレベルを業界団体で決めて、その基準をクリアしに行くというマッチポンプ透明性のある取り組みが求められているということだろう。

この記事が気に入ったらサポートをしてみませんか？