Google Cloud Assured Open Source Software を検証しました

ゼロバンク・デザインファクトリー DevOps チームの鈴木です。
開発生産性を高めつつ安全なシステム開発ができるように環境整備に取り組んでおります。

Google Cloud Assured Open Source Software (AOSS)を導入検証しましたので、その知見を紹介します。
2023年8月時点での内容です。　

# モチベーション

ソフトウェアサプライチェーン攻撃というサイバーセキュリティ上の脅威があります。
現在のソフトウェア開発はオープンソースなくして成立せず、その恩恵に依存している一方で、オープンソースのパッケージに悪意が混入した場合の脅威も大きくなっています。稼働するシステムを守るだけでなく開発工程の段階で安全性を確保する取り組みが必要になります。
由来の確かなオープンソースパッケージを利用することで、ソフトウェア開発ライフサイクルを守っていきたいと考えています。

# Google Cloud Assured Open Source Software とは

Google Cloud Assured Open Source Software(AOSS) がどんなサービスかというと

* Google によって、選別されたオープンソースパッケージが、継続的に脆弱性スキャンされ、 保護された Cloud Build でビルドされ、来歴と署名が確認でき、Artifact Registry から配信される

というものです。

https://cloud.google.com/blog/products/identity-security/introducing-assured-open-source-software-service?hl=en

署名された来歴によってソフトウェアサプライチェーンに対抗するためのフレームワークである [SLSA-2](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) で Level1, Level2, Level3 の保護を達成しています。

# 導入

他の Google Cloud のプロダクトと異なり、[申込みフォーム](https://developers.google.com/assured-oss) から利用を開始します。
申込時には連絡先の他にAOSSを利用するためのサービスアカウントの情報を送信します。このサービスアカウントに次の権限が付与されます。

* パッケージが配信される AOSS の  [Artifact Registry](https://cloud.google.com/artifact-registry/docs) からのダウンロード
* [Artifact Analysis APIs](https://cloud.google.com/artifact-analysis/docs) のアクセス
* SPDX, VEX といったパッケージのメタデータが保存されている [Cloud Storage bucket](https://cloud.google.com/storage/docs) のアクセス
* パッケージステータスや脆弱性の更新情報を受け取る [Pub/Sub topic](https://cloud.google.com/pubsub/docs) のsubscribe
    

Pub/Sub トピックは 申し込みフォームで指定する公開された HTTPS エンドポイントである必要があります。受け取った情報は　Slackにポストするなど任意で扱えばよいかと思います。

# 活用

AOSS として現在サポートされているのは Java と Python のパッケージです。
[どのようなパッケージが利用可能かはドキュメントに記載](https://cloud.google.com/assured-open-source-software/docs/supported-packages) がありますが、Artifactr Registry API を利用して確認するのがよいでしょう。
まずは GitHub で公開されている AOSSのサンプルのプロジェクトを利用してみます。
https://github.com/google/aoss-springboot-sample-starter-project
手順はサンプルプロジェクトのREADMEにありますが、コマンド部分だけを抜粋すると次のようになります。

```console
$ git clone https://github.com/google/aoss-springboot-sample-starter-project.git
$ cd gradle
$ ./setup.sh PATH_TO_SERVICE_ACCOUNT_KEY
$ gradle clean build
$ cd app
$ ./generate_report.sh PATH_TO_SERVICE_ACCOUNT_KEY
Number of packages coming from AOSS: 19
Number of packages coming from the public repository: 99
List of packages coming from AOSS:

org.apache.logging.log4j:log4j-core:2.17.1
org.springframework.boot:spring-boot-starter:2.7.8
org.springframework.boot:spring-boot:2.7.8
org.springframework:spring-core:5.3.25
org.springframework:spring-context:5.3.25
org.springframework:spring-aop:5.3.25
org.springframework:spring-beans:5.3.25
org.springframework.boot:spring-boot-autoconfigure:2.7.8
ch.qos.logback:logback-classic:1.2.11
ch.qos.logback:logback-core:1.2.11
org.apache.logging.log4j:log4j-api:2.17.2
org.slf4j:jul-to-slf4j:1.7.36
org.slf4j:slf4j-api:1.7.36
...
```

AOSS から 19、public repository から 99 のパッケージが入手されたというレポートと AOSS パッケージのリストが表示されました。


# パッケージの検証

次にダウンロードされたパッケージを [ドキュメント](https://cloud.google.com/assured-open-source-software/docs/package-signature-overview)に従って、 https://github.com/google/aoss-verifier を利用して検証してみます。

```console
$ aoss-verifier set-config PATH_TO_SERVICE_ACCOUNT_KEY
$ pwd
~/src/github.com/google/aoss-springboot-sample-starter-project/gradle/app
$ aoss-verifier verify-package --language java --package_id org.apache.logging.log4j:log4j-api --version 2.17.2 --artifact_path build/install/app/lib/log4j-api-2.17.2.jar
File downloaded at tmp_downloads/org.apache.logging.log4j:log4j-api-2.17.2-2023_08_24_17:02:05/buildinfo.zip
File downloaded at tmp_downloads/org.apache.logging.log4j:log4j-api-2.17.2-2023_08_24_17:02:05/package_signature.zip
File downloaded at tmp_downloads/org.apache.logging.log4j:log4j-api-2.17.2-2023_08_24_17:02:05/package_signatures/ca.crt
Certificates verified successfully!
Signature Verified successfully!
```

buildInfo、 package_signature がダウンロードされ、証明書と署名が検証されます。
buildInfo.json には誰が、いつ、どこから入手したどのバージョンのソースコードを、どうやってビルドしたか、といった [メタデータ情報](https://cloud.google.com/assured-open-source-software/docs/access-metadata-using-cloud-storage) が含まれています。

上のコマンドにさらに `--verify_build_provenance` フラグをつけると build provenance (ビルドの来歴)を検証することができます。
類似のツールで [slsa-verifier](https://github.com/slsa-framework/slsa-verifier) があるのですが、Google Cloud Build の Artifacts は WIP(Work In Progress) となっており、2023年8月時点では対応しておりませんでした。

# Remote/Virtual Repository

ここまでで紹介した手順はサービスアカウントの認証を利用するものでした。
サービスアカウントでの認証だとローカルの開発環境でそれぞれの開発者がパッケージをAOSSからダウンロードするためには、サービスアカウントキーが必要になってしまいクレデンシャルの配布や管理の問題が発生してしまいます。
JFrog Artifactory や Sonatype Nexus、そして Artifact Registry には複数のレポジトリを透過的に扱う機能があり、それを利用すると個々の開発者にサービスアカウントキーを配らずにパッケージのダウンロードを実行するができるようになります。
https://cloud.google.com/assured-open-source-software/docs/remote-repository-access

JFrog Artifactory、 Sonatype Nexus ではサービスアカウントキーを登録して利用することで RemoteRepository として AOSS を設定することができます。
一方、Artifact Registry では AOSSに登録したサービスアカウントを、Artifact Registry Agent として実行することで AOSS の  Repository をアップストリームとした Virtual Repository を設定することができます。Virtual Repository への権限を付与することで個々の開発者は 自分たちで管理する Artifact Registry を通して、AOSS のパッケージをダウンロードすることができます。
ポイントは申込フォームで  [Artifact Registry のサービスアカウント](https://cloud.google.com/artifact-registry/docs/ar-service-account) に権限付与されるように登録することです。もう一つは Artifact Registry の Virtual Repository は 同一リージョンに作成する必要があるため、AOSS の Repository がある US リージョンに作成しなければならないことです。

# まとめと感想

AOSS によって保護されたオープンソースパッケージを利用することでソフトウェアサプライチェーン攻撃へ一定の防御となりえそうです。

AOSS は利用料金が無料となっています。申し込みフォームでは Google Cloud のサービスアカウントの他に AWS アカウントへの権限付与もできることが特徴的だと感じました。 GitHub上 の関連レポジトリも `GoogleCloudPlatform` ではなく、 `google` であったことが Google 社のオープンソースへの関わり方の一端としてセキュリティに寄与しようという雰囲気を私は感じています。
今後、Java と Python 以外の パッケージ、特に Docker Container の配布や ASIA 地域の Registry の設置にも期待したいです。

みんなの銀行/ゼロバンク・デザインファクトリー では今後もセキュアなソフトウェア開発に取り組んでいきます。
We’re hiring!