ref: https://blog.sigstore.dev/verify-oci-container-image-signatures-in-kubernetes-33663a9ec7d8

本篇文章要探討的也是跟 security 有關的一個概念，一樣也是基於 Software Supple Chain 這個概念去探討到底環境中用到的相關軟體是否都是安全且被信任的。

本文章分享的是一個基於 Kubernetes Admission Controller 實作的解決方案 Connaisseur，該解決方案的概念很簡單
1. 透過 Admission Controller 去監聽系統上所有 Container 的部署請求
2. 如果部署的 Container Image 是符合事先設定規則的，則允予通過
3. 如果不符合，該次部署就直接失敗

所謂的規則比較簡易的說法就是簽章，只有包含了可信賴簽章的 Container Image 才會被 Connaisseur 給允許通過

有了這個基本概念之後，下一個問題則是到底什麼是可信賴簽章？以及要如何讓想要使用的 Container Image 獲得一個可信賴的簽章?

文章內介紹了關於 Container Signatures 的一些演變，包含了 Docker Content Trust, Notary(V1) 以及 The Update Framework 早期的使用方式
到後來因為 OCI(Open Container Initiative) 的發展與調整，目前可以直接於 OCI Image Spec 一同夾帶該 Image 相關的簽章。
這意味者任何支援該 OCI 標準的 Container Registry 不但可以存放該 Container Image 同時也可以存放該 Image 的簽章。
這個使用方式的變更也促使了 Notary 這個開源專案(v2)的演進。

與此同時， Linux 基金會底下的 Sigstore 專案也再努力地針對開源專案的簽章方面努力著，期望能夠透過簽署與驗證功能來提升開源專案簽署方面的應用。
Sigstore 專案底下的 Cosign 小專案則是專門處理 OCI Image 相關的簽章事項，包含簽署，儲存以及驗證。

而本文所開頭所提及的 Connaisseur 專案則是可以基於 Cosign 所簽署的內容去進行驗證，透過兩者的配合可以用來確保部署到 Kubernetes 的所有 Image 都需要被 Cosign 給簽署過
作者特別強調，目前 Sigsotre 以及 Cosign 這些專案都還是屬於開發階段，所以 Connaisseur 本身對於這項功能的整合也是屬於一個開發實驗階段，很多東西都會不穩定
隨者資安意識以及相關事件 Solarwinds hack 等的出現，當各團隊基本的 DevOps, CI/CD 文化與流程都逐漸成型後， DevSecOps 的東西就會是下一個各團隊要開始煩惱的地方了
特別是所謂的 Software Supply Chain 上的各種潛在危險。

ref: https://medium.com/devopscurry/securing-your-ci-cd-pipelines-with-devsecops-in-2021-1a6a6e34f2e7

本篇文章作者想要探討的是如何透過 DevSecOps 的概念來強化你的 CI/CD 流程。

文章開頭探討了些關於 DevOps 文化以及對團隊帶來的改變，如何將 Dev, Ops 的工作流程給帶入到一個不同的領域，這部分想必大家都熟識了，所以這邊就不敘述太多。

接者作者開始思考，CI/CD 這種自動化的過程中，如果我們想要檢查資安與安全性相關，那到底有什麼樣的資訊市值得我們去檢查與研究的?

假設今天採用的是市面上 SaaS 服務的所提供的 Pipeline 平台，這些平台本身的資安問題並不是使用者可以去處理的，這方面只能仰賴這些服務提供商能夠有效且安全的去防護系統。因此作者認為我們應該要將注意力放在我們自行設計的 pipeline 過程中。

作者接者列舉了幾個議題，譬如

1. Source Code Vulnerabilities
這個議題要檢查的是軟體本身是否有相關的漏洞

2. OSS Library Vulnerabilities
所有使用到的 OSS Library 也都可能有漏洞需要注意，所以平常也要多注意 CVE 相關的資訊，有任何可以修復的機會時，團隊一定要評估是需要升級相關的 OSS

3. OSS Version
OSS 的社群也是會不停的開發與迭代，某些版本可能多年後就不被該社群團隊給維護，所以如果目前使用的 OSS 版本已經被標示為 deprecated，那意味就算有任何漏洞可能都不會有相關維護者去補修。因此團隊也要審慎評估是否要趕緊升級到一個有被維護的版本

4. Identifying Compromising Credentials
CI/CD 系統中不免都會有一些跟機密資訊有關的資料，這些資料是有可能當初處理時沒有被妥善管理，譬如不小心被 commit 到 source code 之類的，這部分的錯誤也都要避免。

檢查方面，作者提出不同的方式來檢查，譬如
1. Static Application System Testing(SAT)
程式編譯前的靜態掃描，該方法會嘗試分析程式碼本身是否有安全性漏洞，也是俗稱的白箱測試。

2. Active and Passive penetration t est (Dynamic Analysis)
3. Infrastructure Analysis
該方法包含了檢查環境中用到的設定檔案，伺服器狀態等，透過這些資訊來了解當前是否有什麼潛在的問題

最後，作者列舉出一些相關的工具，譬如
1. Checkmarx
2. IMMUNIO
3. Aqua Security
4. OWASP Zed Attack Proxy
5. Twistlock
6. CyberArk
7. WhiteSource
8. CHef InSpec
9. Fortify Webinspect

今天帶來的內容是關於 DevSecOps 的介紹，由 synk 這間公司所撰寫的 DevSecOps 介紹，與其說是文章更像是一個專欄，內文非常豐富，從基本的介紹，到文化，人員組成，運作流程以及相關技術探討都包含其中，我認為對這個領域有興趣的人很值得花些時間咀嚼一下這系列文章，來看看到底別人認知的 DevSecOps 到底是什麼。

本篇文章針對 overview 的部分進行介紹，其餘詳細部分請到連結中閱讀囉

What is DevSecOps:
1. 將 Security 的概念帶入到 DevOps 的軟體交付流程
2. Dev & Ops 共享責任來交付安全的應用與軟體

從功能面來看，盡可能地於整個軟體開發交付流程中盡可能早的發現安全並且修復，要特別注意的是"安全是所有人共享的責任"並不是單純 DevOps 團隊人員的責任，大夥還是努力合作一起解決問題，就如同 DevOps 的概念一致。

6 Benefits of the DevSecOps Model
- Faster delivery: 將 Security 等概念整合到軟體交付流程中時，可以讓任何漏洞於正式部署前就發現與解決，這樣可以使得整體的開發流程更加順利與快速。
- Improved security posture: 資安不再是個上線後才要擔心的議題，而是打成軟體設計開發初期就要關注的點，透過這個方式才有辦法把資安跟建置，部署進行一個緊密的整合
- Reduced costs: 正式部署前能夠定位找到任何 vulnerabilities 能夠有效率地減少各種維運上的風險成本。
...等

原文非常有趣，非常推薦有興趣的閱讀這整篇專欄

https://snyk.io/devsecops/