💡 今日學習目標：理解程式碼審查 (Code Review) 與靜態檢測 (SAST) 的運作原理，掌握自動化工具如何透過語法樹與污點分析抓出潛藏漏洞。

📌 前言：踏入階段二「資安是檢查出來的」

歡迎來到階段二！在前五天的觀念篇中，我們建立了「軟體品質即資安」的思維。現在，我們要回到現代工業品質發展的第一階段：「品質是檢查出來的（Inspection）」。

接下來六天（Day 06 - Day 11），我們都會待在這一階。

在軟體開發中，當我們剛寫完程式碼，還沒部署上線之前，最直接的防守方式就是 「檢查程式碼」 。

這種檢查主要分為兩大陣營：

1. 人工檢查：同行審查（Peer Code Review）。
2. 自動化工具檢查：靜態應用程式安全測試（SAST - Static Application Security Testing）。

今天，我們就來拆解這兩種檢查方式的運作精髓與通則原理！

🔍 核心原理：Code Review vs. SAST 靜態檢測

同樣是「檢查一份原始碼」，這兩種方式擅長的東西完全不同：

1. 同行程式碼審查 (Peer Code Review)

由團隊的另一位工程師閱讀你的 PR / Merge Request。它最大的價值在於：只有人類看得懂商業邏輯。

「這個折扣可以無限疊加嗎？」「這支 API 憑什麼讓一般會員呼叫？」這類問題，工具永遠問不出來。

痛點也很現實：人會累。面對數萬行的專案，靠肉眼要抓出藏在語法細節裡的字串拼接或硬編碼金鑰，非常困難。

2. 靜態程式碼檢測 (SAST)

在不執行程式的前提下，直接分析原始碼（Source Code）或編譯後的 Bytecode，幾秒鐘內比對數千條安全規則。它不會累、不會分心，也不會因為這個 PR 是主管開的就放水。

但它有兩個必須認清的極限：

• 誤報（False Positive）：把其實安全的寫法標成漏洞。這會慢慢消耗團隊的信任，久了大家就開始無視所有告警。
• 漏報（False Negative）：真的有漏洞，但它沒抓到。這個更危險：「SAST 全綠」不等於「系統安全」，它只代表「沒有踩到工具認得的那些樣式」。

📎 順帶釐清一個很容易混淆的地方：Day 05 提過測試階段要「SAST + DAST」並行，兩者的差別就在執不執行程式。

SAST 不執行程式、直接讀原始碼，像是拿著設計圖找結構問題；DAST 則是把系統跑起來，對著執行中的網站實際發送惡意請求，像是拿工具去敲門看鎖牢不牢。

兩者抓到的漏洞類型不同，不能互相取代。本系列的動手做集中在 SAST，因為它是最容易零成本導入的那一個。

💡 SAST 的底層原理：污點分析 (Taint Analysis)

SAST 工具到底是怎麼在不執行程式的情況下發現漏洞的？
絕大多數 SAST 工具的核心通則，就是基於 「抽象語法樹（AST）」 與 「污點分析（Taint Analysis）」 。

它的概念其實非常直覺：把每一筆從外部進來的資料都當成「髒的」，然後一路跟著它，看它最後會流到哪裡去。

污點分析的四個核心概念

1. 污點源（Taint Source）：不可信的外部資料流入點。
   • 例如：HttpRequest.GetParameter()、URL Query、Form Input、上傳的檔名。
2. 污點傳播（Taint Propagation）：資料在變數之間被賦值、傳遞或轉化的過程。
   • 只要一個變數碰到了「污點」，它自己也會被標記為受污染，然後繼續往下傳染。
3. 危險匯點（Taint Sink）：敏感或危險的系統執行函數。
   • 例如：DB.Execute()（可能引發 SQLi）、Shell.Exec()（可能引發 Command Injection）、Response.Write()（可能引發 XSS）。
4. 淨化函數（Sanitizer）：能夠移除污點標記的函數。
   • 例如：參數化查詢的參數綁定、HTML Entity Encode、Shell 參數跳脫。

第四個是整套機制裡最關鍵、卻最常被忽略的一環。

理解了它，你就會明白一件事：SAST 之所以會在你把字串拼接改成參數化查詢之後就不再告警，不是因為你「把它弄安靜了」，而是因為它認得那個 API 是一個合法的淨化點，污點在抵達危險匯點之前就已經被清掉了。

這也是判斷「你到底有沒有真的修好」的標準：你插進去的那一步，是真的淨化，還是只是讓工具看不懂？

⚠️ 先埋一個伏筆：污點分析是 SAST 裡最耗運算、也最值錢的能力，因此它幾乎是所有商業工具用來劃分免費版與付費版的那條線。

明天介紹工具的時候，我們會正面處理這件事，包括筆者推薦的那套免費方案，它的界線畫在哪裡。

🛠️ 開發者的 SAST 防守 CheckList

觀念講完了，這裡給你三個可以直接帶著走的操作原則：

• [ ] 不要為了讓工具閉嘴而改程式碼：如果你的「修復」只是把寫法繞開偵測樣式，污點其實原封不動還在那裡。修好的標準是「有沒有插進真正的淨化」，不是「紅字有沒有消失」。
• [ ] 標記誤報時一定要留下原因：有些告警在你的情境下確實無害，這時該做的是標為安全並寫下理由，而不是無聲地把整條規則關掉。後者會讓下一個接手的人踩進同一個坑。
• [ ] 越早開掃越好：新專案第一天就把掃描打開，累積的問題永遠是個位數；等到三萬行才導入，你會拿到一份沒有人想面對的清單，最後全部被標成「以後再說」。

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

• 🔹 心法 1：人工與自動化並重。Code Review 看邏輯，SAST 抓漏洞。
• 🔹 心法 2：理解污點分析（Taint Analysis）。追蹤資料從污點源（Source）流到危險匯點（Sink）的全程，而修漏洞的本質，是在中間插進一個真正有效的淨化函數（Sanitizer）。
• 🔹 心法 3：全綠不等於安全。SAST 會誤報也會漏報，它只能證明「沒踩到它認得的樣式」，剩下的仍要靠人。

💬 明日預告：【Day 07】沒預算買商業檢測工具？免費開源的 SonarQube 家族登場！
明天我們會破解商業工具動輒數十萬元的迷思，介紹人人都能免費使用的方案，同時也誠實告訴你，免費版的界線究竟畫在哪裡。