CI事業部セキュリティセクションの村上です。re:Inforce 2024 参加のため、米国フィラデルフィアに来ています。
早いもので、本日でイベント3日目にして最終日になります！

サーバーレスのソフトウェアサプライチェーンのセキュリティに関する Builders’ Session （1時間のハンズオンワークショップ）に参加してきました。

セッションタイトル：APS353 | Elevate serverless software supply chain security with SLSA
スピーカー：Niaz Khan, Ying Ting Ng, Guy Gutman, Purnaresa Yuliartanto

サプライチェーンにおけるセキュリティ上の課題

ソフトウェアサプライチェーンにおけるセキュリティ上の課題としては、
開発者不足、データプライバシー、OSS の適切な利用、コードの完全性が挙げられます。

97%のアプリがオープンソースを使用していると言われています（出典不明）。

ソフトウェア開発におけるセキュリティ上の脅威としては、下図のようなものが挙げられます。(https://slsa.dev/spec/v1.0/threats-overview より)

A. 認証されていない変更
B. ソースリポジトリの改ざん
C. 変更されたソースからのビルド
D. 改ざんされた依存関係の使用
E. ビルドプロセスの改ざん
F. 変更されたパッケージのアップロード
G. パッケージレジストリの改ざん
H. 改ざんされたパッケージの使用

このようなソフトウェアサプライチェーンにおける脅威に対応し、OSS を安全に活用するため、OpenSSF のプロジェクトである SLSA というフレームワークと、 OpenSSF Security Scorecard を活用できます。

OpenSSF とは

OpenSSF（Open Source Security Foundation）は、 OSS のセキュリティ確保のために活動している、ソフトウェア開発者、セキュリティエンジニアなどのコミュニティです。AWS も出資しています。

SLSA とは

Supply-chain Levels for Software Artifacts（SLSA）は OpenSSF のプロジェクトで、ソフトウェアサプライチェーンのセキュリティフレームワークです。「サルサ」と読みます。

改ざんを防止し、完全性を保ち、パッケージとインフラを守るためのチェックリストからなります。開発者の指標となるとともに、ソフトウェア消費者は SLSA を参考に、ソフトウェアを信頼するかどうか決定することができます。

SLSA には1〜4の4段階の Assurance Level があり、Level 4 が最もセキュアです。
SLSA Level 1 では、ビルドプロセスのコード化・自動化が必要です。
SLSA Level 2 では、SLSA Level 1 に加えて、バージョン管理やソフトウェア署名などが求められます。
※ 本当はもう少し細かい定義がありますが、ここでは概要のみ記載します。詳細はこちらです。

Software Bill of Materials（SBOM）が材料なら、SLSA は調理法・調理場所のようなものです。

OpenSSF Security Scorecard とは

OpenSSF Security Scorecard は、オープンソースプロジェクトを18項目の自動チェックでスコア化し、評価するツールです。

含まれるパッケージの脆弱性だけでなく、リポジトリのブランチ保護状況、メンテナンス状況などから、総合的にリスクを評価します。
スコアは10点評価で、高いほうがベストプラクティスに沿っています。

使用方法はこちらです。GitHub Action でも実行可能です。

AWS で SLSA を実践するには

AWS Lambda で稼働するアプリで SLSA 2 を達成するには、AWS Signer と AWS CodePipeline を利用できます。

ハンズオンシナリオ

AWS CodeCommit からソースを取得して、AWS Lambda を更新する、次のようなパイプラインを構築していきました。

  1. CodeCommit からソースを取得
  2. CodeBuild で OpenSSF Security Scorecard を使って OSS 評価、結果出力
  3. CodeBuild でビルド
  4. CodeBuild + AWS Signer で署名
  5. CodeDeploy で Lambda にデプロイ

時間の都合上、CodeBuild のビルド定義のファイルは用意されており、CodePipeline にステップを追加していき最後に実行する、という形でした。

Lambda の設定により、署名されていないソースファイルによる更新を防止することもできます。
実際に署名していないソースを Zip 化したものをコンソールからアップロードして更新しようとすると、更新が拒否されました。

ビルドプロセスがコード化され、AWS Signer による署名もされたことで、SLSA 2 を満たすことができました。
また、Scorecard の利用により、使用している OSS の評価もパイプライン中で行うことができました。

おわりに

Lambda などのサーバーレス環境では、手軽にソフトウェアを実行できる反面、そのソフトウェアが信頼できるか、サプライチェーン攻撃に対して堅牢であるかなどは評価が難しくなっています。

ソフトウェアサプライチェーンを評価する SLSA や、 OpenSSF Security Scorecard による OSS 評価を活用することで、信頼できるコードか評価するとともに、AWS Signer により安全でないコードのデプロイを抑止する事ができました。

ソフトウェア開発のリスクを管理する方法の一つとして、本手法を取り入れてみるのはいかがでしょうか？