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 這個專案有興趣看看的請參考原始連結，內容不長但是頗有趣的

這篇文章算是一個資安問題的討論文章，作者透過一系列的手法成功地獲取了大量使用者的電腦資訊，由於這次的實驗只是要證明資安問題，因此作者的程式只有獲取如 IP, Hostname 等簡單資訊，若是惡意的話是可以執行更多危險程式碼的。

作者開門見山表示，現在的程式語言有太多的豐富的第三方函式庫，譬如 NodeJs(NPM), Ruby(RubyGem), Python(PyPI)，豐富的第三方實作讓開發者可以更快速的完成任務。
開發者在使用這些套件函式庫時，大部分情況都不會去檢查太多，而是直接信賴般的去使用這些函式庫，而這種盲點般的信任是否有可能讓攻擊者有跡可循？

作者基於這個想法進行了一系列研究，發現 PayPal 公開專案(NodeJs) 內的 package.json 內交互使用了公開與內部的 packages。 公開部分勢必來自 npm 而那些內部的應該是來自於 PayPal 內部系統，同時也注意到這些內部的 package name 目前於 npm 上也不存在。

針對這個情境，作者提出一些問題
1) 如果有人上傳跟 PayPal 內部 package 相同名稱的套件到 npm 服務器上，有沒有可能 PayPal 內部某些專案會預設使用 npm 上的套件而非內部自架的伺服器?
2) 開發者或是其他自動化系統有沒有可能運行這些 packages 內的程式碼，這樣有沒有機會造成一個漏洞的可能性？
3) 其他的公司是否也會有類似的問題?

為了證實這個問題，作者設計了一系列的實驗與準備來測試上述問題，譬如更有系統的去尋找這種有跡可循的 package.json(Tesla, Apple, Yelp 等公司都被到可以利用的 package names)。

作者將自己這系列的攻擊行為稱為 depdendency confusion 來呼應本文標題。

結果來看是令人非常震驚的，作者打造同名的npm的確被大量下載與執行，也讓作者收集到大量運行的內部服務器IP與名稱。
與 Apple 合作通報相關報告後， Apple 也於兩週內修復相關問題。

原文滿長的，非常推薦閱讀
我個人認為資安這概念就是不出問題不被重視，但是一但出問題可能造成的影響卻非常巨大的。團隊內每個人都要培養基本的資安理念，同時與相關的安全團隊合作逐漸地提高整個產品的安全性，永遠不要想一聲令下明天就可以反轉一切。

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

—課程已於 2020 年 8 月更新—

本課程是關於使用 Microsoft 和 Docker 公司所提供的最新技術從頭開始建構電子商務 Web 應用程式，這技術基於微服務架構，使得應用程式的微服務全部運行在其獨立容器中，並在需要時通過訊息(messaging)彼此溝通，在其它狀況下 mvc 客戶端將協調微服務的行為。我們將有 5 個微服務運行，包括 mvc 客戶端應用程式。
本課程還教你如何 docker 化你的微服務專案，利用 docker 資料庫容器和建構一個 docker-compose 檔案，以實現微服務容器建立的自動化。
本課程還將教你如何通過基於 IdentityServer4（利用 OAuth2 和 OpenIDConnect 協議）與AspNet Identity 協作建構的認證伺服器微服務來保護你的 web apis 和你的 mvc 客戶端應用程式。
最後，你將學習在某些情況下，可能需要兩個微服務發送訊息給對方取得間接通信。 RabbitMQ伺服器與 MassTransit 、 Autofac Dependency Injection Library 以及一些相關的 nuget 套件協作，將會提供我們一個事件匯流排 ( evnt bus )，通過它我們可以實現這一點。
本課程充滿了最新的想法和技術，這將使你在當今快速發展的技術世界武裝大量的技術。

https://softnshare.com/aspnet-core-20-e-commerce-web-site-based-on-microservices-and-docker/