前言
延續 DevOps，DevSecOps 一詞在 IT 圈內也已經不是一個新詞，市面上有非常多的廠商都在銷售號稱與 DevSecOps 有關的產品，亦有不少來自資安圈的講師分享過 DevSecOps 的主題。就如 DevOps 一樣，DevSecOps 同樣也具備著「十個講師會有十一種 DevSecOps 的內容」的現象，但無論如何 DevSecOps 絕對是 DevOps 的其中一位後繼者，是當前企業多少會開始了解與碰觸的一項熱門議題。
在今年 2023 的 iThome Cloud Summit，我邀請了 GitLab 原廠的 Staff Solutions Architect - Toshitaka Ito，以及另一位 GitLab Hero - Mouson (墨嗓) ，一起針對 DevSecOps 這個主題，規劃了一場「輕輕鬆鬆體驗 DevSecOps」的 Hands-on Lab。
議程簡介
這次投稿的是 Hands-on Lab，以下是本次提供給主辦單位的議程簡介資訊：
延續 DevOps 風潮，其實 DevSecOps 一詞自 2012 年被人提出後，至今也超過 10 年了。DevSecOps 作為一個根源自 DevOps 而來的新詞，我們會發現它跟 DevOps 一樣有著「似乎沒有標準定義」、「不同企業的實踐方式皆不相同」的現象。
課程目標
• 認識 DevSecOps • 體驗來自 GitLab 的 DevSecOps 流程 • 實際體驗如何修復程式碼中含有的漏洞
課程綱要
- 先以簡報解說與本 Lab 相關的 DevSecOps 重點觀念，了解本次 Lab 會涉及的觀念、技術與實作範圍。
- 說明本次 Lab 提供的體驗環境。
- 搭配簡報說明與現場實作，帶領學員一步步幫進入狀況，體驗 Lab 事先設計好的 DevSecOps 情境。
簡報與範例程式碼
簡報：輕輕鬆鬆體驗 DevSecOps @ iThome Cloud Summit 2023
範例程式碼：https://gitlab.com/gitlab-learn-labs/sample-projects/quick-devsecops-hands-on-workshop
特別說明：
本次 Lab 使用的是 GitLab.com 提供的 Training Environment。在該環境 User 可以直接體驗 GitLab 提供的完整 DevSecOps 功能。Training Environment 是需要特別向原廠申請才能使用的環境，一般的使用者無法直接使用。因此要向大家說聲不好意思的是，你看了這份簡報可能也無法直接復現 Lab 的所有操作步驟。
為何這次 Lab 選擇使用 Training Environment，而不是用更開源或開放的環境呢？這部分的原因我會一併在下面的內容中說明。
（再次感謝 GitLab 原廠 SA - Toshitaka Ito 協助向原廠申請 Training Environment。）
輕輕鬆鬆體驗 DevSecOps
老實說，如果你打算嘗試自己在 CI/CD Pipeline 中加入各種開源的 Security 掃描工具，然後將工具掃出來的 Report（多半是各種 xml 或 json）組合在同一個 Dashboard 或 UI 上，那真的一點都不輕鬆。
雖然整件事做起來不難，但如果你考量到中間要花費的各種整合、串接、客製與後續維護成本，你會發現它還真是不太「輕鬆」。
基於上面的原因，在和夥伴一起構思這次 Lab 的內容時，我們很早就放棄「讓學員自己整合開源工具、組裝出 Security Dashboard」的想法，因為這實在不輕鬆，在 Lab 有限的空間與時間限制下，我們決定讓學員將學習的重點放在「實踐 DevSecOps 的第一步」。
為了讓學員不要將注意力放在「整合 Security 掃描工具很辛苦」，最後我們選擇使用 GitLab 原廠提供的 Training Environment 來作為本次 Lab 的環境；在 Training Environment 中，學員可以免費的使用 GitLab 全套完整的 DevSecOps 功能，只需要簡單的在 .gitlab-ci.yml 中 include: 原廠早已準備好的 CI Templates，就能替 Pipeline 加上全套的 Security 掃描，這滿足了 Lab 的第一個目標——必須是「輕輕鬆鬆的體驗」。
第二個目標是讓學員將學習重點放在「實踐 DevSecOps 的第一步」，這裡我們希望學員在 Lab 過程中，能注意到「工作流程」及 CI / CD Pipeline 的「變與不變」。也就是說實踐 DevSecOps 的「第一步」其實並沒有大家想像的那麼難，特別是如果你的團隊已經有一套穩定的「工作流程」及 CI / CD Pipeline 時，那其實「第一步」並不會對你的團隊帶來劇烈的變化。
實踐 DevSecOps 的第一步
那麼到底什麼是「實踐 DevSecOps 的第一步」？
在這次的 Lab 中我們的看法是，將你現有的「工作流程」及 CI / CD Pipeline 繼續延伸至「Security 掃描」並且做出第一階段的「Security 左移」。
如果你的團隊很成熟，那麼你們可能已經有採行某種版本控制的 Branch 策略，遵守規定的 Release 規範與原則，並且也有 Code review 及 CI / CD Pipeline。
這時候，其實你可以很簡單的開始在 CI / CD Pipeline 中加入 Security Scan。
當開發工程師在 Feature branch 工作時，就會有 Pipeline 進行 Security Scan 的 CI Job，確保他的程式碼在合併回主要 Branch 前，就能及早發現 Security Issue。甚至可以設置必要的 Merge request approval rules，規定 Feature branch 在合併回 Main branch 前，必須通過哪些 Approval rules，促進團隊落實 Code Review 與 Security Review。
針對 Main branch，其 Pipeline 也會有 CI Job 進行 Security Scan，產出完整的 Security Report，讓 Security Issue 能和其他 Feature、Bug 一樣在第一時間被團隊知曉，得以排入團隊的工作任務清單之中。
透過上述在「工作流程」及 CI / CD Pipeline 的簡單調整，我們可以開始讓團隊邁向第一階段的「Security 左移」，讓「Security 掃描」不再是團隊在交付軟體或部署上線的最後一刻才被執行的事情；想必大家都聽過這樣的故事，隔天就是公司對外公告的新版產品上市日，但今天資安團隊才告訴開發團隊說「你們有 N 個 Security Issue 需要修補，修完才准上線」，請問最後導致產品無法準時上線的鍋，到底應該要誰來背呢？
小結
這次的 Lab 依然是一個入門班等級的內容，畢竟 Security 是一個巨大的議題，除了軟體及程式碼本身的 Security，其實像是你的開發環境、正式環境、Infra、甚至是 CI / CD Pipeline 本身，也都有著各自需要關注的 Security 議題，這裡面需要不同 Security 專家的專業知識與智慧。
因此本次的 Lab 希望傳達的觀念是，我們並不需要一開始就對團隊的運作做出劇烈的改變，也能開始嘗試實踐 DevSecOps，逐步地將「重視 Security」的意識帶進你的團隊，讓團隊在追求「提升產品品質」時，那個「品質」之中能包含著「Security」。
而這一切的改變，就從你自己最容易開始的地方做起吧！
畢竟萬事起頭難，但如果你永遠都不起頭，那它永遠都難啊！
最後的最後，再次感謝原廠的 Toshitaka Ito 與 GitLab Hero - Mouson (墨嗓) ，感謝他們兩位在我邀請一起合作這場 Lab 時，第一時間就答應參與，並且提供了非常多的幫助，如果少了他們，這場 Lab 是無法順利舉辦的，他們才是這場 Lab 的最大功臣，感謝兩位！
活動照片
（開放式的場地，因此學員必須戴著耳機才能聽見講師的聲音。）
（是啊，從哪裡來呢？）
（GitLab Hero 出任務，感謝 Mouson 拔刀相助！）
（GitLab Hero 出任務，感謝 Mouson 拔刀相助！）
（GitLab 原廠所繪製的 DevOps Lifecycle 中，Secure 是涵蓋全面的。）
