前言
安全軟體的建構不靠銀彈，靠的是開發者的日常習慣。以下整理自數千位優秀開發者的共同特質，助你打造更安全的代碼。
習慣 1：勇於負責
產品安全性最終由撰寫代碼的你負責。工具 (靜態分析、編譯器警告) 只能輔助，無法取代人腦判斷。請務必：
- 親自審查所有代碼，假設所有輸入都會被攻擊。
- 邀請安全專家進行專業代碼審查，而非泛泛之談。
- 善用所有可用資源：最高警告等級編譯 (/W4、-Wall)、靜態分析工具、防禦性語言結構 (如 C#
checked 關鍵字防整數溢位)。
習慣 2：永不信任輸入
所有輸入在驗證通過前均視為惡意。CVE 數據顯示 47% 漏洞源於輸入信任問題 (緩衝區溢位、SQL 注入、XSS、XPath/LDAP 注入)。
防禦三原則：
- 白名單驗證：只接受已知合法格式 (如正則表達式限制)，而非黑名單過濾已知惡意字元。
- 拒絕可疑輸入：檔名含
..、| 等直接拒絕，回應通用錯誤訊息 (「找不到檔案」) 而非洩露內部邏輯。
- 輸出編碼：Web 應用輸出不可信資料前務必 HTML 編碼，防 XSS。
習慣 3：建立威脅模型
威脅模型不僅用於設計階段，更能指導代碼審查重點：
- 識別資料來源：遠端/本地、匿名/認證用戶/管理員。
- 遠端匿名可存取的代碼路徑需最嚴格審查、最多防禦層。
- 高價值資料 (商業機密、PII) 必須有額外保護措施 (加密、存取控制、稽核)。
- 沿著匿名資料路徑追蹤代碼，檢查每個處理節點的正確性。
習慣 4：保持領先
威脅日新月異，必須持續學習：
- 定期閱讀軟體安全經典著作。
- 訂閱 Bugtraq (securityfocus.com) 等漏洞資訊，設規則歸類處理。
- 從自己與他人的錯誤中學習，建立組織知識庫。
習慣 5：實施模糊測試
模糊測試 (Fuzzing) 以大量異常輸入觸發崩潰，發現可靠性錯誤 (約 1% 可演變為安全漏洞)。
- 所有解析檔案格式、網路封包的代碼必須經過模糊測試 (建議 10 萬次迭代)。
- 崩潰不等於單純拒絕服務，可能隱藏任意代碼執行風險 ——「今天的 DoS 是明天的 RCE」。
- 微軟 SDL 要求對所有解析器進行檔案格式模糊測試，並提供工具與原始碼。
習慣 6：拒絕寫入不安全代碼
品質把關 (Quality Gate) 機制：
- 代碼提交前必須通過靜態分析工具掃描，零警告才能入庫。
- 禁用危險函數：
strcpy, strncat 等 (微軟禁用 100 多個 CRT 函數)。
- 禁用弱加密演算法：DES、MD4、MD5 (除非標準強制)。
- 避免重複造輪子：共用經驗證的解析庫，減少攻擊面。
- 工具不能替代安全教育，開發者必須深入理解原理。
習慣 7：認清攻防非對稱性
攻擊者只需找到一個漏洞，防禦者必須修補所有漏洞，且受預算、相容性、時程限制。策略：
- 定期審查舊代碼，修復歷史安全債。
- 採用靈活開發流程時，安排專人重構舊模組至新標準。
- 淘汰不再維護的不安全功能，而非繼續打補丁。
習慣 8：善用最佳工具
- 靜態分析工具能快速掃描海量代碼，量化風險熱點。
- 最高警告等級編譯：大量警告往往暗示潛在邏輯錯誤，需優先審查。
- 工具是加速器，非替代品 —— 結合人工審查與自動化掃描達到最佳效果。
總結
這八個習慣不會讓你瞬間成為安全大師，但能構建持續改進的安全文化。從今天開始，對自己的代碼負責，不信任任何輸入，建立威脅模型，保持學習，模糊測試，拒絕不安全寫法，審視舊代碼，善用工具。
