前言
延續 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 是涵蓋全面的。)