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 這個專案有興趣看看的請參考原始連結,內容不長但是頗有趣的
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「dependency專案」的推薦目錄:
- 關於dependency專案 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於dependency專案 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於dependency專案 在 軟體開發學習資訊分享 Facebook 的最佳貼文
- 關於dependency專案 在 コバにゃんチャンネル Youtube 的最讚貼文
- 關於dependency專案 在 大象中醫 Youtube 的最佳貼文
- 關於dependency專案 在 大象中醫 Youtube 的最佳解答
- 關於dependency專案 在 Re: [請益] 關於"大型專案"的定義- 看板Soft_Job 的評價
- 關於dependency專案 在 傳遞依賴(transitive dependency) 的評價
- 關於dependency專案 在 Waterfall 瀑布式專案管理,搭配#Dependencies 功能- YouTube 的評價
- 關於dependency專案 在 多個套件具有相同的相依性時 的評價
- 關於dependency專案 在 Meta Business SDK 入門指南 的評價
- 關於dependency專案 在 將Glide 新增到你的專案中 的評價
dependency專案 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
這篇文章算是一個資安問題的討論文章,作者透過一系列的手法成功地獲取了大量使用者的電腦資訊,由於這次的實驗只是要證明資安問題,因此作者的程式只有獲取如 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
dependency專案 在 軟體開發學習資訊分享 Facebook 的最佳貼文
—課程已於 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/
dependency專案 在 傳遞依賴(transitive dependency) 的推薦與評價
為了降低多個專案間的複雜度, 我們通常會謹慎的控制專案之間的依賴, 但在最近新開案的.NET Core 一系列的新專案中發現傳遞依賴會讓專案之間產生預期外 ... ... <看更多>
dependency專案 在 Waterfall 瀑布式專案管理,搭配#Dependencies 功能- YouTube 的推薦與評價
![影片讀取中](/images/youtube.png)
歡迎來到 不哲不扣的高效人生大家都在用Notion ,你會了嗎? 最近Notion 頻繁更新功能,主要針對 專案 管理作優化,讓我們來看看 專案 管理要用哪些特定 ... ... <看更多>
dependency專案 在 Re: [請益] 關於"大型專案"的定義- 看板Soft_Job 的推薦與評價
每間公司對"大型"的定義不同。
不同角色在專案中的關注點不同,專案經理跟研發就會看不同的面向。
要先把範圍框出來才有辦法討論。 最簡單的做法就是,把數量丟給對方。
對方會自己決定,對他而言,這樣是大還是小專案。
假設要問的是研發類型的角色好了,會從幾個角度去看。
1. 參與的人數
人數越多,溝通複雜度越高。
都在同一個單位,還是跨單位合作?
=> 直接影響到version control跟Build system。溝通的機制也會複雜化
2. Scope
多大的系統
例如同時負荷多少concurrent user
=> 100, 10K, 1M背後的系統架構差很多
3. Schedule
理論上時間越長,專案越複雜。但隨著Agile概念起來,不太有以前Waterfall
那樣的長週期專案。
會注意到就是Dependency的問題,尤其是跨部門溝通合作。
UI/UX、RD、QA、Operation、MKT之間,一個卡一個,如何處理。
資深一點的都該知道,自己的角色在哪塊。怎樣的行為會影響到前後的流程,
而不是只有自己寫完往後丟就算結束。
4. Impact
投入成本這點研發人員很難清楚知道,都只有推算。
要量化的話,直接說使用者有多少? 這個產品位公司帶來的營收有多少?
會比較容易讓對方有概念。
※ 引述《binghuanlin (BH_Lin)》之銘言:
: 各位前輩好,
: 小弟最近在和同事們討論,對於"大型專案"的定義。
: 不論是在工作上或面試時,都有意無意會提到,
: "有沒有維護或參與過大型專案",
: 這個時候,就衍生出一個問題,
: 何謂大型專案?
: 以下為小弟我在網上找到的對於"大型專案"的定義:
: <https://en.wikipedia.org/wiki/Megaproject>.
: 原文:
: According to the Oxford Handbook of Megaproject Management,
: "Megaprojects are large-scale,
: complex ventures that typically cost $1 billion or more,
: take many years to develop and build,
: involve multiple public and private stakeholders,
: are transformational, and impact millions of people".
: [2] However, $1 billion is not a constraint in defining megaprojects,
: as sometimes (e.g. in developing countries)
: a relative approach is needed because in some contexts,
: a much smaller project (such as one with a $100 million budget)
: could constitute a megaproject.
: Therefore, a more general definition is
: "Megaprojects are temporary endeavours (i.e. projects) characterized b
: y:
: large investment commitment,
: vast complexity (especially in organizational terms),
: and long-lasting impact on the economy, the environment, and society".
: 大體上似乎專案的"大型"也就是其規模,是取決於
: A: 投入成本。
: B: 影響人數
: C: 複雜度。
: 而在Wiki這裡面有提到一些數字:
: 1. 投入成本: 10億美金
: 2. 影響人員: 100萬人
: 所以,如果照著wiki裡的講法,以上二者成立,才能算是"大型專案"嗎?
: 請各位前輩不吝指教和討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.233.130
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1527793373.A.FA2.html
... <看更多>