Ref: https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

今天要探討的是一個由 Google Blog 於上個月所推廣的軟體安全性框架，該框架名為 SLSA，全名則是 Supply Chain Levels for Software Artifacts，中文部分我不知道該怎麼翻譯才可以精準達到意思，所以建議就唸英文就好了。

該框架的目的是希望於整個軟體生產鏈中能夠進一步的去提升且確保所有產物的完整性(Integrity 這個詞該怎麼翻呢..)。

文章中用了一個很簡易的流程來清楚的解釋到底何謂 Software Supply Chain 以及整個流程中可能會有什麼問題。

Software Supply Chain 一個範例譬如
1. 開發者撰寫程式碼，並且提交到遠方的 SCM Repository
2. SCM Repo 因為程式碼改變，所以觸發相關的 CI/CD 流程
3. CI/CD 建置結束後則需要打包整個程式碼，產生最後的 Package.
4. 產生後的 Packet 則可以正式上場使用

文章認為上述的流程中有兩個不同類別的安全性問題，分別是
1. Source Integrity
2. Build Integrity.

Source Integrity 這邊主要是針對 Source Code 相關的問題，譬如
1. 開發者是否有意的故意塞入一些會不懷好意的程式碼到 SCM Repo 內。
範例: Linux Hypocrite commits, 之前美國某大學研究團隊基於研究嘗試上傳一些不太好的程式碼而影響的討論風波
2. SCM 的管理平台是否可能被惡意攻擊
範例: PHP 事件: 之前自架的 PHP Git Server 被攻擊者惡意攻擊並且塞入兩筆不懷好意的 Commit

而 Build Integrity 本身則是有更多不同的面向，譬如
1. SCM 觸發 CI/CD 過程是否有可能有問題
範例: Webmin 事件，攻擊者去修改團隊的建置系統去使用沒有被 SCM 所記錄的修改檔案。
2. CI/CD 建置系統本身被攻擊
範例: SolarWinds 事件，攻擊者攻破建置系統去安裝一些軟體來修改整的建置流程
3. CI/CD 建置過程中引用到錯誤的 Dependency
4. 攻擊者上傳一些惡意產物到應該只有 CI/CD 系統才可以存取的場所。
... 等

目前來說， SLSA 還處於非常早期階段，經由業界的共識來思考每個領域有什麼好的措施與指引來避免與偵測系統是否被攻破。其最終目標狀態是希望能夠根據環境自動產生出一套可整合到系統中的產物，並且最後可以給出 SLSA 憑證來給平台或是建置後的 Package。

對 SLSA 這個專案有興趣看看的請參考原始連結，內容不長但是頗有趣的

最近看到一個很好笑的開源專案的對話：
一個人添加了一個新的 library， 並提交了一個 pull request 。其中一個管理者說：
Okay this is awesome. I'll test it out and merge when I get home. Thanks! (好的， 這看起來很棒， 我回家後會測試並合併到主支)
留言時間： Mar 18, 2013

另一個人回覆：
Sorry for rushing this a bit, but got home yet? (抱歉好像有點趕你， 但你回到家了嗎？)
留言時間： Dec 17, 2020 (上一個回覆的 7 年半後...XD）

管理者一個月後：
I have no clue how to test this locally anymore, so in the spirit of this commit...Fuck It! I just merged and we'll see what happens.
（我現在完全不知道要怎麼樣在我的機器上測試了， 考量到這個提交是要加入 Fuckit library， Fuck it. 我不管了，我就直接合併到主支， 看會發生什麼事...）😅

原 PR 提交者：
I knew you’d be back one day. Godspeed chief. （我就知道你某一天一定會回來的， 上帝祝福你大大）😆

完整對話出處：https://github.com/gkoberger/stacksort/pull/4

手刻二階段提交（Two-phase Commit），處理分散式交易的其中一種解法。

https://dotblogs.com.tw/supershowwei/2019/02/25/233819