iT邦幫忙

2026 iThome 鐵人賽

DAY 5
0

💡 今日學習目標:掌握 Secure SDLC (安全軟體開發生命週期) 的全貌,學會在軟體開發的 5 大環節中植入資安防守機制。


📌 前言:被資安打回重寫的惡夢

你有沒有遇過這種慘痛的經歷?

專案團隊歷經了幾個月的努力,好不容易完成訪談、設計、寫完程式碼並通過測試。就在準備上線的前一週,公司的資安團隊或外部滲透測試廠商進場掃描,結果開出一張長長的不合格漏洞報告:

❌ 「資料庫存取未做架構層面的權限隔離,架構需重繪。」
❌ 「密碼與敏感資料以不安全加密方式儲存,資料庫 Schema 需重設計。」

這意味著:已經寫好的 Code 要大改,資料庫結構要重拉,上線時間被迫延後!

這就是典型的「把資安放在最後一關」所付出的代價。

Day 02 我們說了「資安要左移」。但左移到底是要「移去做什麼」?

今天就把這句口號拆開來:把常見**軟體開發流程(SDLC)**的五個環節攤在桌上,每一格各自該做哪些事,一項一項列出來。


🔍 核心原理:常見開發流程 vs. Secure SDLC (S-SDLC)

傳統軟體開發流程通常包含五大環節:

訪談/需求 ➔ 系統設計 ➔ 程式開發 ➔ 系統測試 ➔ 部署上線

如果我們要在這五個環節中切入資安防守,究竟每個環節該做些什麼?


🛠️ Secure SDLC 5 大環節資安切入點解析

Secure SDLC 五個環節的資安切入點,並標示本系列各階段對應的篇章

圖上每一格右下角的 Day,就是這 30 天裡會帶你動手做的地方。你可以先把這張圖存起來,後面每走完一個階段,就回來對照一次。

環節 1:訪談與需求 (Requirements) — 定義資安防守線

  • 核心任務:在討論商業功能時,同時將「資安與隱私需求」寫入需求規格書中。
  • 開發通則 CheckList
    • [ ] 系統涉及哪些敏感資料?(如個人身份證號、信用卡號、密碼)
    • [ ] 系統需要遵守哪些法規或標準?(如 GDPR、個人資料保護法、PCI-DSS)
    • [ ] 系統的角色與權限等級如何定義?(管理員、一般使用者、訪客)

環節 2:系統設計 (Design) — 設計防守架構

  • 核心任務:在畫系統架構圖與 API 設計時,進行威脅建模 (Threat Modeling)
  • 開發通則 CheckList
    • [ ] 系統模組之間的信任邊界(Trust Boundaries)在哪裡?
    • [ ] 資料傳輸是否全程採用 HTTPS / TLS 加密?
    • [ ] 是否採用最小權限原則與縱深防禦(Defense in Depth)架構?

環節 3:程式開發 (Development) — 撰寫安全程式碼

  • 核心任務:開發人員遵守 Secure Coding 指南,並在本地環境安裝 IDE 輔助工具。
  • 開發通則 CheckList
    • [ ] 開發環境安裝 SonarQube for IDE(即原本的 SonarLint),在寫程式的同時進行即時漏洞掃描。
    • [ ] 對所有外部輸入做強制強型別驗證與 Sanitization。
    • [ ] 拒絕使用硬編碼(Hardcoded)的金鑰或密碼,改用環境變數管理。

環節 4:系統測試 (Testing) — 自動化漏洞掃描

  • 核心任務:結合靜態檢測(SAST)與動態測試(DAST),在整合測試環節揪出潛藏漏洞。
  • 開發通則 CheckList
    • [ ] 執行 SonarQube 靜態程式碼分析,確保沒有高風險的 Security Hotspots。
    • [ ] 檢查第三方套件與 Open Source 函式庫是否有已知漏洞(SCA / Dependency Check)。
    • [ ] 針對重點 API 進行邊界測試與異常輸入測試。

環節 5:部署上線與維運 (Deployment & Operation) — 持續防護與應變

  • 核心任務:透過 CI/CD 自動化防禦與系統日誌監控,確保上線後的持續安全。
  • 開發通則 CheckList
    • [ ] 部署管道(GitHub Actions / GitLab CI)整合自動化 Security Scan。
    • [ ] 關鍵操作與失敗嘗試紀錄完整的 Audit Log(審計日誌)。
    • [ ] 建立事件應變通報流程(Incident Response Plan)。

🎯 今日重點小結與防守心法

  • 🔹 心法 1:資安貫穿整個 SDLC。需求、設計、開發、測試、部署,每一個環節都有對應的資安任務,沒有哪一格可以跳過。
  • 🔹 心法 2:設計環節決生死。架構層面的資安瑕疵,發現得越晚、修復成本越高,這個差距在大型專案上可以拉開到百倍等級(這個數字的真實出處與適用範圍,Day 12 會細談)。
  • 🔹 心法 3:做好準備進入動手做。觀念已經備妥,接下來我們要用開源工具親自動手了。

🚀 階段一完結:從「知道」走向「做到」

到今天為止,我們完成了階段一:前言與觀念篇(Day 01 - Day 05)

這五天,我們從槍林彈雨下的網際網路環境出發,接住了被踢來踢去的資安皮球,借品質演進史建立起四階段的防守視野,戳破了「資安就是 SQLi 加 XSS」的認知盲點,最後把資安防守一格一格嵌進了 SDLC。

到這裡為止,觀念的部分結束了

接下來,我們即將進入:階段二 — 資安是「檢查」出來的

Day 06 開始,正式進入 【動手做】 的部分。我們會用完全免費的工具(SonarQube for IDE 與 Docker 版的 SonarQube Community Build),架設你人生的第一個資安檢測站,親手掃出、也親手修好第一個漏洞。

記得 Day 01 說的嗎?這 30 天,一毛錢都不用花。


💬 明日預告:【Day 06】「檢查」第一步:什麼是 Code Review 與靜態程式碼檢測 (SAST)?
明天我們將正式踏入階段二,揭開開源靜態掃描工具的神秘面紗!


上一篇
【Day 04】專家與開發者的盲點落差:你以為只防 SQLi/XSS,其實駭客玩的是這些!
系列文
槍林彈雨下的資安防守:從品質觀念切入,帶開發者從零動手作資安 30 天5
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言