Supply chain Levels for Software Artifacts

Google Blog 裡面最近寫了一篇有關於軟體攻擊的文章,這邊來拜讀。

SLSA

Supply chain integrity attacks(供應鏈攻擊),在 source ➞ build ➞ publish 的 workflow 中存在著許多威脅,此手法為在使用 sorftware package 的時候被注入惡意的行為,進而去感染用戶端,而且此方法在近幾年中也被證實可行性。 在近幾個月也數以百萬的攻擊(e.g. SolarWinds, Codecov)。目前就很需要一個架構讓開發者們使用,來阻擋這些惡意攻擊。

而 Google 就提出一個解決方案 Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”),此方案為 end-to-end 的框架,來確軟體供應鏈的安全。 SLSA 主要增強目前軟體安全性的狀況,特別是針對 open source,來防止威脅。

How SLSA helps

此圖顯示了所有可能被攻擊的環節。在文中有解是各個攻擊環節的範例,以及改進方針。

下圖為引用 Google Bolg 上面的圖片 attacks that can occur at every link in the chain

環節 問題 改善
A 開發者有意無意推了有漏洞的 code 上 SCM 找人 code review,但無法確保找出全部漏洞
B 軟弱的 SCM,被推送惡意代碼 更好的保護 SCM 讓攻擊變困難
C SCM 觸發 CICD 的代碼被修改 Build server 鑑定代碼的來源
D Build platform 被安裝惡意行為的代碼,隨後將惡意代碼植入到被編譯的軟體上 Build platform 進行更有效的安全機制,使攻擊變困難
E 攻擊者注入無害的相依套件,隨後修改其套件加入惡意行為 檢查所有相依套件,檢查是否有餐參照其他來源
F 攻擊者獲取 bucket 上傳密鑰,並上傳檔案到 GCS bucket。檔案上傳並非 CICD 流程的產出物 GCS bucket上的檔案必須顯示檔案來源是否為 CICD 產出物
G 軟弱的軟體庫,研究顯示流行的鏡像軟體庫,使用有惡意的軟體套件 惡意套件顯示不是按照預期的流程與來源建構的
H 攻擊者上傳名稱與流行套件很像的惡意套件,欺騙開發者使用 SLSA沒直接解決這問題

What is SLSA

SLSA 的框架是由 4 個階段所組成。

下圖為引用 Google Bolg 上面的圖片 SLSA 4 levels

  • SLSA 1 要求構建過程完全腳本化/自動化並標示編譯出處。
  • SLSA 2 需要使用版本控制和編譯後的驗證碼。
  • SLSA 3 進一步要求源和構建平台滿足特定標準,以分別保證來源的可審計性和出處的完整性。
  • SLSA 4 是目前最高級別,需要兩個人審查所有更改和密封、可重複的構建過程。

References

  1. 供應鏈攻擊鎖定GitHub開源軟體專案
comments powered by Disqus