大家好，這是 2026-06-20 的 Tempest Security Daily。今天經過篩選後僅有一篇主題完整的長文：Orca Security 發表的「What Is Application Security Testing? Tools and Types」，由於該文涵蓋面廣，從 AST 整體框架、各種測試型態、雲端情境到實務 FAQ 一網打盡，本期將以該篇為核心拆解成多段重點摘要，方便團隊內部分享。
一、什麼是 AST：流程加上工具，而不是單一產品
應用程式安全測試（Application Security Testing, AST）指的是「在軟體開發生命週期裡找出並修復安全缺陷」的整套流程與工具集合。原文特別強調 AST 不是單一工具，而是一個包含測試、修補流程與治理（governance）的完整計畫，目標是降低設計瑕疵、含有漏洞的相依套件、或不安全預設值流入正式環境的機率。對台灣團隊而言，這也呼應「安全要進 CI/CD，不要等滲透測試發報告」的內部宣導方向。
二、Shift-Left：在開發者還有上下文時就修才划算
文章提出 Shift-Left 安全的核心理由：在發佈後才修的成本，遠高於設計或 code review 階段就解決。重點在於趁開發者還記得上下文時補救，遠比後續再回頭追查歷史 commit 來得有效率。但作者也提醒，安全不應該只到 deployment 為止，runtime 濫用、供應鏈事件、雲端組態錯誤仍會在發佈後浮現，因此 AST 必須與應用程式安全治理一起搭配，把範圍涵蓋 API、批次工作與整合介面，不能只盯使用者介面。
三、威脅建模（Threat Modeling）：在程式定型前先想清楚對手
威脅建模的價值在於「在程式定型前」就確認攻擊者、進入點、與有價資產，常見方法有 STRIDE 與 PASTA。產出包括資料流圖（DFD）、信任邊界、優先排序的濫用情境，這些都能反過來成為 SAST 與 DAST 的規則依據。原文提醒威脅模型會老化：當你加入身分聯合（identity federation）、新外部 API、或會改變資料 lineage 的 AI 功能時，就必須重新檢視。建議把模型當作程式碼一起放進 repo，跟架構變更一起 review。
四、SAST：在 IDE 與 CI 早期攔截注入、硬編密鑰
SAST 分析原始碼或編譯後的中介碼，不執行整個應用即可找出注入、弱加密、硬編密鑰、不安全的 API 用法等樣式。文章給出的可靠落地建議有三：調整規則與抑制（suppressions）以降低 false positives、把發現透過漏洞管理流程指派到具體 owner、檢視 SAST 對你的實際技術棧（含 IaC 模板）覆蓋是否到位。對 CI/CD 治理較成熟的團隊，可順手在每次 PR 觸發 SAST 並把高風險規則設為阻擋條件。
五、SCA：開源相依與 SBOM 的可見度
SCA 盤點開源與第三方元件、比對已知漏洞、標示授權風險。原文用「Log4j 到底用了哪一行版本」當作經典場景。重點實務有：每個 release 都產生並保存 SBOM、為私有 fork 與 vendored 程式碼設定政策、把 SCA gate 同樣套用到內部 mirror（不是只防公開 registry）。文章也強調 SCA 不會取代修補紀律，它的功能是「當新漏洞冒出來時讓影響範圍立刻可見」，仍須有對應 patch 流程。
六、DAST：跑起來的應用、爬出來的弱點
DAST 透過爬蟲與 fuzzing 從外部介面打應用，需要一個能反映正式環境 auth 與路由的部署環境，能找出組態錯誤、auth bypass 及 runtime-only 才會出現的問題。文章點出兩個常被忽略的細節：深層工作流要靠 scripted authentication，否則 DAST 會走不到那段邏輯；以及 rate limit 與 WAF 會影響掃描結果，需與維運協調掃描時段，並盡量使用獨立測試 tenant，避免被誤判為攻擊或拖累正式環境。
七、IAST：把 SAST 的精準度帶到 runtime
IAST 在運行中的應用裡植入 instrumentation，結合 runtime 觀察與程式碼意識（code awareness），能追蹤 HTTP 參數一路到 sink 的 taint flow，補上 SAST 與 DAST 中間的縫隙。原文提醒部署前要先評估三件事：runtime overhead 與營運歸屬、若 PII 流經被追蹤路徑會不會涉及隱私風險、staging 與正式環境路由或測試資料是否一致。一旦 IAST 報出 sink，建議再對照 SAST 與 DAST 結果確認可達性與可利用性，不要單一工具喊就修。
八、模糊測試與滲透測試：例行 AST 之外的補強
原文把滲透測試與紅隊演練視為不同於日常 AST 的活動：滲透測試對 staging 或近似正式環境模擬對手，常帶有自動化掃描省略的創意與社交工程元素，應該排在「行事曆級」週期執行；而 SAST 與 SCA 則應該每次 merge 都跑。模糊測試（fuzzing）以畸形輸入餵 parser 與通訊協定處理器找 crash 與記憶體錯誤，AFL++ 之類工具在 C / C++ 元件中相當常見，能補 SAST 對 native code 的不足，但需要良好的 build 整合與 crash triage 紀律。
九、權威框架對齊：NIST SP 800-218、OWASP ASVS、CISA KEV
文章引用三個權威資源作為 AST 治理的對齊依據：NIST SP 800-218（SSDF）作為將安全整合進軟體交付的廣用框架；OWASP Application Security Verification Standard（ASVS）幫助把安全需求翻譯成 SAST、DAST 與人工 review 的具體測試案例；CISA Known Exploited Vulnerabilities 目錄則在 AST 與威脅情報同時點到同一個 CVE 時，作為修補優先級的依據。建議把這三個框架放進內部「資安規範索引」當常駐連結。
十、雲端情境：用 IAM、暴露面、攻擊路徑重新排序漏洞
原文以 Orca Cloud Security Platform 為例，說明 AST 工具找的是 repo 與測試環境的問題，但正式環境還多了 IAM 權限、公開暴露、密鑰、跨帳號攻擊路徑等風險。同樣一個高風險 finding，若位於孤立的 build server 與位於有路徑直通客戶資料的對外 workload，其優先級完全不同。建議把雲端 context（agentless SideScanning、CNAPP 視角）拉進來重排優先級，避免團隊被 CVSS 分數綁架。
十一、優先級與頻率：把 AST 嵌入 SDLC 的節奏
FAQ 段落整理了實務常被問的兩件事。首先是優先級：應結合嚴重程度（如 CVSS）、可利用性、資產暴露（對外 vs 內網）、資料敏感度，落在關鍵且暴露的系統上的 finding 要先處理。再來是頻率：AST 應整合進整個 SDLC，而不是一次性評估；多數團隊每次 code change 都跑 SAST 與 SCA、測試週期跑 DAST、有重大架構變更時重訪威脅模型。這套節奏可以作為內部資安政策的版型。
十二、起手式與成熟度指標：小團隊先做什麼、如何衡量成效
對小團隊而言，作者建議從 CI/CD 上的 SAST 加 SCA 起步，再依風險與系統複雜度延伸 DAST 或人工測試。衡量 AST 計畫是否成熟的關鍵指標包括：mean time to remediate（平均修補時間）、因關鍵問題被阻擋的 build 比例、重複出現漏洞的下降幅度，以及「掃描器報的問題」與「真實事故」之間的關聯度。對台灣中型工程組織，這些指標可以直接寫入年度資安 OKR。
結語
今天的篩選結果只有一篇主題完整的長文，但 Orca Security 這份 AST 全景式整理本身就足以當作部門內部訓練教材：從 SAST、SCA、DAST、IAST 到威脅建模、雲端情境與成熟度指標，建議分配兩到三位工程師依組別認領段落，週會挑一段落作 15 分鐘簡報並對應到自家流水線是否已落實。明天見。