欸，我們來聊聊 SSDLC 吧，別把它想得太複雜
今天想來聊聊「SSDLC」，就是那個… Secure Software Development Life Cycle，軟體安全開發生命週期。我知道，光聽名字就覺得很硬、很像那種寫在教科書裡的東西。老實說，一開始我也覺得這東西八成又是什麼管理顧問發明出來的KPI項目。
不過呢，接觸久了，特別是踩了幾個坑之後，我發現…它其實沒那麼可怕。
先說結論：SSDLC 其實就是一套「預防勝於治療」的開發習慣，把「安全」這件事，從專案一開始就放進去，而不是等到最後要上線了才來抱佛腳。 就像蓋房子，你不會等蓋完才想水管電線要怎麼拉，對吧？一開始就要規劃好。
想像一下這個場景…是不是有點熟悉？
我想起之前帶過的一個案子，團隊裡的工程師都超強，寫扣很快、功能交付也準時。但他們就是…嗯…把「安全」當作是QA或維運團隊的事。他們覺得，寫好功能是首要任務，安全掃描什麼的，是上線前的「儀式」。
結果，就在預計上線前一週，我們請外部團隊做了個滲透測試，同時內部也跑了DAST掃描…哇，那報告出來，真的是滿江紅。什麼 SQL Injection、Cross-site Scripting，還有一些權限控管的邏輯漏洞，全冒出來了。
我還記得那天的會議，整個團隊的臉都綠了。PM的臉色更是難看。最後，產品上線日硬生生延了三個禮拜，團隊每天都在修補這些其實在開發早期就能發現的問題。這就是典型的「安全債」，而且是利息最高的那種高利貸。這件事也讓大家意識到，把安全檢查延到最後，成本真的太高了。
好啦，那到底怎麼做？步驟與要點
所以，要怎麼避免上面那種慘劇？其實就是把安全工作「左移」（Shift-left），越早開始越好。 聽起來很抽象，我把它拆成幾個實際的階段來講，你可能會比較有感覺。
第一站：需求與設計階段（動手寫扣之前）
這真的是最最最重要，也最容易被忽略的階段。在大家還在畫線框圖、寫規格文件的時候，就要把安全想進去。
這聽起來又是一個專有名詞，但你把它想像成「在蓋房子前，先想好小偷會從哪裡進來」。例如：
- 使用者登入的地方，密碼會不會被暴力破解？
- 使用者上傳檔案的地方，會不會有人上傳惡意程式？
- API 的溝通，中間會不會被攔截偷看？
- 後台管理員的權限，是不是太大了？會不會有員工帳號被盜用，然後整碗被捧走？
把這些可能的「威脅」都想一遍，然後在設計階段就規劃好對策，比如「登入要加上二次驗證」、「上傳檔案要掃毒」、「API 全都要用 HTTPS 加密」等等。這個階段的討論，會比寫了一萬行程式碼後才來改，成本低太多了。
參考資料怎麼用？
這時候，可以拿出大名鼎鼎的 OWASP ASVS (Application Security Verification Standard) 來參考。 老實說，這份文件非常…龐大。對新專案或小團隊來說，一開始就想做到 Level 3 是不切實際的。 我會建議從 Level 1 開始，把它當成一個 check list，看看哪些是你的應用程式必須要做的。
另外，如果你是在台灣做金融相關的應用，那可能就要特別留意了。除了國際通用的標準，台灣金管會其實也有一些相關的規範，像是《金融機構辦理電子銀行業務安全控管作業基準》或是針對電子支付、App 的規範。 這些規範雖然用詞跟 ASVS 不太一樣，但精神是相通的，尤其在存取控制、資料加密、變更管理這些地方，要求都蠻嚴格的。 所以，與其盲目追求 ASVS 的高等級，不如先把 Level 1 的基本功練好，然後對照台灣本地的法規，把交集的部分優先實作出來。
第二站：開發實作階段（工程師的主場）
好，設計都想好了，終於要開始寫程式了。這個階段的重點是，不要拖慢開發速度，但又要能即時發現問題。
核心工具：靜態應用程式安全測試 (SAST)
SAST，全名是 Static Application Security Testing。 你可以把它想像成一個超級強大的拼字檢查工具，但它不是檢查文法，而是檢查你的程式碼裡有沒有已知的安全漏洞寫法。 比如說，它會掃描你的原始碼，看看有沒有地方寫了容易導致 SQL Injection 的程式。
這類工具的好處是，它在你程式碼寫完、甚至還沒執行的時候就能檢查。 現在很多 SAST 工具都能整合到開發環境 (IDE) 或是 CI/CD Pipeline 裡。 開發人員一提交程式碼，系統就自動掃描，如果發現高風險問題，就直接擋下來，不讓有問題的程式碼合併進主幹。這就像是在源頭就把污染擋住。
第三站：測試與部署階段（上線前的最後把關）
程式碼寫完，也整合成一個可以運作的版本了。這時候，就要換另一種方式來測試它。
核心工具：動態應用程式安全測試 (DAST)
DAST，Dynamic Application Security Testing。 這個跟 SAST 完全不同。DAST 不看你的程式碼，它直接去「攻擊」你正在運行的應用程式，模擬駭客的行為，從外部嘗試找出漏洞。 比如，它會對你的登入頁面不斷嘗試不同的帳號密碼，或是對你的搜尋框輸入惡意字串，看看系統會不會出錯。
DAST 的好處是，它能發現一些只有在系統實際運行時才會出現的問題，例如伺服器設定錯誤、或是跟其他系統互動時產生的漏洞。它的觀點更接近真實攻擊者。
說到這裡，很多人會搞混 SAST、DAST，還有一個叫 IAST 的東西。我簡單整理一下，讓你比較好懂。
| 類型 | 這是什麼？ | 優點 | 缺點 |
|---|---|---|---|
| SAST (靜態分析) | 嗯…這個就像看建築藍圖抓問題。程式碼還沒跑，它就先掃一遍，是「白箱測試」。 | 超早就能發現問題，修起來成本最低。 而且它可以地毯式掃描整個程式碼庫，覆蓋率很高。 | 它看不懂實際運行的狀況，所以會有不少「誤報」。有點像疑心病太重，看到黑影就開槍，需要人工判斷。 |
| DAST (動態分析) | 這就像請一個蒙面的測試員，在不看藍圖的情況下，去推牆、敲窗戶，看看哪裡不牢固。這是「黑箱測試」。 | 抓到的問題通常都蠻真實的，誤報比較少。而且能測到伺服器設定、環境相關的漏洞。 | 一定要等程式可以跑了才能測，發現問題時已經比較晚了。而且它沒辦法告訴你是哪一行程式碼出錯，除錯比較花時間。 |
| IAST (互動式分析) | 這個比較新，算是上面兩者的混合體。 它像是在運行的程式裡放了個探員，有人從外面攻擊(DAST)，它就在裡面看資料怎麼流(SAST)，所以能精準定位問題。 | 準確率很高，既能發現真實漏洞，又能直接告訴你問題在哪一行程式碼。 誤報率低。 | 通常需要在應用程式裡裝一個代理程式(agent)，可能會對效能有那麼一點點影響。而且…嗯…通常也比較貴。 |
常見的錯誤與修正
聊了這麼多，我想分享一些我看到很多人在導入 SSDLC 時，最常犯的幾個錯。
- 把工具當銀彈：這是最常見的迷思。很多團隊花了錢買了很棒的掃描工具，然後…就沒有然後了。工具掃出來的報告堆積如山，紅字一堆，但沒人去看、沒人去修、沒人去追蹤。這比不買工具還糟糕，因為它給了你一種「我們有在做安全」的虛假安全感。
- 追求完美，結果動彈不得：有些團隊，特別是技術力很強的，一開始就想把所有事情都做到最好。想導入最完整的 ASVS Level 3、想把所有工具都串上 CI/CD、想讓誤報率降到零…結果光是規劃就花了半年，什麼事都沒開始。我的建議是，從最小的可行性產品 (MVP) 開始，先挑一兩個最重要的點，比如在 CI/CD 中加入 SAST，先跑起來再說，有成果之後再慢慢擴大。
- 把安全變成開發的敵人：如果安全團隊只是不斷地丟報告給開發團隊，要求他們在時程壓力下修正漏洞，那很快就會變成對立關係。 比較好的做法是，把安全團隊當作「教練」，提供教育訓練、提供好用的工具、協助判斷漏洞的真偽和優先級。最終的目標是讓開發者自己就有安全意識，而不是靠別人來檢查。 這其實就是 DevSecOps 文化的核心。
所以，這不只是一張查檢表
講到最後，你會發現 SSDLC 根本不是一張可以打勾的「查檢表」而已。 它更像是一種文化，一種把安全內化到開發流程每個角落的思維模式。 它需要工具的輔助，但更需要的是人的意識和流程的配合。
從一開始的需求分析就想好安全，到開發中用工具輔助，再到測試階段的驗證，最後是上線後的持續監控與應變。 每個環節都多想一點，就能避免掉很多未來的麻煩跟半夜被叫起來救火的惡夢。
那你呢？你在團隊裡導入安全流程時，覺得最卡關、最痛苦的地方是什麼？是工具太難用、找不到人？還是跟開發團隊的溝通讓你心很累？在下面留言分享一下你的經驗吧！
