Googleは、ソフトウェアサプライチェーン攻撃の脅威拡大に対処する手段として、「Supply-chain Levels for Software Artifacts」（SLSA）フレームワークを提案している。SLSAは「サルサ」と発音される。
高度な技術を持つ攻撃者は、ソフトウェアサプライチェーンがソフトウェア業界の弱点であることを把握している。Googleは、大きな衝撃を与えたSolarWinds製品に対する攻撃や、先頃の「Codecov」へのサプライチェーン攻撃について指摘している。Codecovのインシデントでは、Codecovの「Bash Uploader」スクリプトが改ざんされ、サイバーセキュリティ企業のRapid7に影響した。
Googleによると、サプライチェーン攻撃は目新しいものではないが、この1年ほどで増加している。同社は、既知の脆弱性やソフトウェアのゼロデイ脆弱性が悪用される問題などからサプライチェーン攻撃へとフォーカスする分野をシフトさせている。
GoogleはSLSAについて、「ソフトウェアサプライチェーン全体でソフトウェアのアーティファクトのインテグリティ（整合性）を確保するためのエンドツーエンドのフレームワーク」と説明している。
SLSAは、Google社内の「Binary Authorization for Borg」（BAB）から着想を得ている。Googleは8年以上前からBABを利用している。BABはコードの出所を確認し、コードIDを実装する。
BABの狙いは、Googleで展開される本番ソフトウェア（特にコードがユーザーデータにアクセスできる場合）が適切に審査、承認されていることを確認し、インサイダーリスクを低減することにあるとGoogleのホワイトペーパーで説明されている。
GoogleのオープンソースセキュリティチームのKim Lewandowski氏とBABチームのMark Lodato氏は、「SLSAの目標は、業界、特にオープンソースの状況を改善して、インテグリティ（整合性）に関する差し迫った脅威から防御することだ。SLSAを使用すれば、顧客は自分が使用するソフトウェアのセキュリティ体制について、十分な情報に基づいて選択することができる」と語った。
SLSAは、開発者からソースコード、ビルドプラットフォームとCI/CDシステム、パッケージリポジトリー、依存関係に至るまで、ソフトウェアのビルドチェーンすべてで脅威を想定している。
SLSAのフレームワークは現時点では、業界のコンセンサスによって定められた付加的に適用できる一連のガイドラインとなっているが、最終的な形は強制力によってベストプラクティスのリストとは異なるものになるとGoogleは構想している。「ポリシーエンジンに取り込まれ、特定のパッケージやビルドプラットフォームに『SLSA認証』を与える、監査可能なメタデータの自動生成に対応する」という。
SLSAは4つのレベルで構成されており、「SLSA 4」はすべてのソフトウェア開発プロセスが保護された理想的な状態となる。
提供：Google
この記事は海外Red Ventures発の記事を朝日インタラクティブが日本向けに編集したものです。