GitHub AI Scan 擴展覆蓋範圍，但合併決定仍由開發人員作主
GitHub AI Scan 於 10 月 15 日正式推出，將安全檢查擴展至 CodeQL 的覆蓋範圍以外，但其發現仍無法阻止合併。這項功能會檢查拉取請求，即提交供審核的擬議變更，並支援指定的程式語言及框架。它為開發人員原本作出發佈決定的位置，新增另一項安全訊號；同時，是否根據該訊號採取行動，仍由這些開發人員負責。
核心張力在於偵測範圍更廣，與可強制執行的保護之間的差異。CodeQL 是 GitHub 用於在不執行程式碼的情況下檢視程式碼的靜態分析引擎，仍然是安全工作流程的一部分。新的 AI 層是補充其覆蓋範圍，而非取而代之。額外的發現會給審核者多一個調查理由，但不會自動成為發佈條件。
這項分別對應用程式開發人員、安全主管及平台團隊均十分重要，因為他們需要判斷現有檢查實際提供甚麼保證。儲存庫可以新增一個警告來源，卻不會因此多一道自動停止機制。實際問題是，審核者能否在程式碼進入生產環境前，將這些警告轉化為有理據的決定。
GitHub AI Scan 在既有檢查以外新增覆蓋範圍
經核實的變更是擴展拉取請求檢查，而非取代 CodeQL。
GitHub 的 AI Scan 發佈公告列出覆蓋範例，包括 PHP、Shell/Bash、Terraform 設定、Dockerfiles、JavaServer Pages 及 Blazor。這些例子涵蓋應用程式程式碼、部署指令及基礎設施設定。GitHub 將此功能定位為補足其現有引擎目前未涵蓋的範疇。
框架層面的分別值得留意。為 C# 指名 Blazor，並不代表 GitHub 新近發現了整個 C# 語言。同樣地，提及 JavaServer Pages 也不代表所有 Java 先前都缺乏分析。覆蓋程度取決於所檢查的特定語言、框架及程式碼。
對開發人員而言，籠統地說某個儲存庫「已被掃描」並不足夠。一個專案可包含多種技術，而每種技術獲得的檢查程度各有不同。能理解應用程式主要語言的檢查，未必能對其範本或部署設定提供同等可見度。
試想一項示例性的應用程式變更，當中包括伺服器程式碼、容器定義及部署指令碼。只審核應用程式邏輯，仍會留下軟件如何啟動及獲授哪些權限等問題。更廣泛的檢查，讓團隊多一個機會發現這些周邊風險。
這個情境說明產品預期扮演的角色；它並非證明引擎能捕捉每一類此等問題。受支援的檔案類型只代表符合檢查資格，並不代表該檔案內所有安全弱點都獲完整覆蓋。
公告亦將發現置於現有審核介面之內。開發人員會看見 AI 標示，以區別於 CodeQL 結果。介面可包括解釋及建議修正方法，縮短發現疑慮與討論受影響變更之間的距離。
這種安排很重要，因為審核者本來已有一項決定要作。獨立報告需要有人把其內容與擬議變更聯繫起來；貼近相關程式碼的發現則直接提供這種連結，儘管仍須有人評估其準確性。
Visual Studio Magazine 在 10 月 23 日的報道，重點提及擴展後的拉取請求檢查。其背後的正式推出公告則較早於 10 月 15 日發出。將兩個日期分開處理，可避免把後來的報道呈現為新產品發佈。
因此，眼前的變更相當具體：符合資格的擬議變更會獲得另一種安全檢查。這帶來有用的額外可見度，同時也引出另一項營運問題：由誰審閱新的發現，以及當審核者意見不一致時如何處理。
更廣泛的偵測令審核能力承受壓力
收到更多發現的團隊，同樣需要明確方法判斷哪些發現值得採取行動。
對應用程式開發人員而言，新增工作始於詮釋。安全解釋需要與應用程式的實際行為相連。審核者必須理解可疑操作是否處理不受信任的輸入、是否接觸敏感資源，或是否在受限制條件下執行。
對安全主管而言，挑戰在於不同儲存庫之間的一致性。不同團隊可以對相似警告作出不同回應。若沒有共識的審核標準，同一項根本疑慮可能在某個專案觸發修正，卻在另一個專案沒有留下任何回應紀錄。
平台團隊還有另一項責任：準確描述覆蓋範圍。啟用功能是一種管理狀態；確保正確的變更獲得有用檢查，則是一項營運成果。內部報告及安全評估應將兩者分開陳述。
GitHub 於 9 月 16 日移除了對 CodeQL 預設設定的早期依賴。其設定依賴變更允許 AI 檢查在沒有該設定下執行。不過，程式碼掃描及相關 AI 設定仍須啟用。
這項變更重要，因為部署阻力會影響安全功能在哪些地方獲採用。團隊不應只為檢查原本符合資格的變更，便必須建立一項無關的分析設定。將這些要求分開，令功能更容易按其自身條件評估。
然而，更容易啟用並不能決定誰負責處理結果。組織分發一項設定，通常比普及安全專業知識容易。審核者仍須具備足夠背景，才能區分有用警告與對不存在問題作出的貌似合理解釋。
公開儲存庫尤其涉及一項重要限制。GitHub 的發佈公告排除了來自 fork 的拉取請求，即用作提出變更的獨立儲存庫副本；亦排除了由 Dependabot 建立的拉取請求，即 GitHub 的相依套件更新服務。維護者在描述審核覆蓋範圍時，應將這些排除情況納入考量。
其含意比「開源專案沒有任何好處」更狹窄。符合資格的變更仍可獲檢查，但維護者不應僅因儲存庫本身公開，便假設啟用功能後涵蓋所有貢獻途徑。
企業買家亦需將存取權與使用量分開。GitHub 表示，私有及內部組織儲存庫需要 GitHub Code Security 或 GitHub Advanced Security，並不需要 Copilot 授權。使用時會消耗 Code Security AI Credits，因此有存取權不代表可無限掃描。
因此，壓力同時落在多個責任人身上。開發人員評估個別警告；安全團隊訂立審核期望；平台及帳單管理員則要令部署與使用量保持清晰。只有當這些責任互相銜接，更廣泛檢查才能帶來預期效益。
這是該次發佈帶來的組織層面後果，而非關於採用情況的量度結論。公告確立了產品行為；至於某個團隊能否有效處理新增工作，仍須由該團隊自行證明。
AI Scan 與 CodeQL 的分別在於互補證據
有用的比較在於每項發現向審核者提供甚麼資訊，而不是哪個引擎在一般競爭中勝出。
AI Scan 與 CodeQL 聽起來像是在兩個互相競爭的替代方案之間作選擇。GitHub 所述的定位支持另一種理解：兩個引擎透過共享工作流程提供發現，同時處理不同的覆蓋範圍。
這項分別改變團隊評估發佈的方式。若比較僅限於共同測試案例，可能會忽略新增層的目的。相關問題還包括，它是否能在原本獲得較少原生檢查的變更中，識別出可採取行動的問題。
同時，額外覆蓋範圍並不是摒棄既有證據的理由。審核者調查 AI 發現時，仍應考慮測試、既有安全檢查及應用程式設計。各者都為決定的不同部分提供資訊。
以實務角度解釋 GitHub AI Scan，它是另一個審核證據來源。它可引導開發人員注意疑似弱點，並建議回應方式；其後，審核者須判斷疑慮是否適用，以及回應是否保留預期行為。
這種分析與 AI 協助的結合已有業界先例。Semgrep 在其公開的分類與修正工程討論中，描述了如何在 AI 工作流程中使用專案背景及靜態分析結果，亦描述了如何透過其分析引擎檢查自動產生的修正。
這項說明提供有用比較，但不足以確立效能排名。Semgrep 描述自身架構及驗證方法；GitHub 描述整合至拉取請求的覆蓋範圍擴展。任何一方的描述本身，都不能證明在客戶程式碼庫上較為優勝。
業界共同面對的問題，是如何把疑似弱點與可信的行動連結起來。找出可疑程式碼是一項工作；解釋其重要性是另一項。產生既能消除風險、又不破壞功能的變更，則增加了進一步要求。
因此，買家不應將 AI 標籤視為完整技術規格。產品可將 AI 應用於偵測、解釋、優先排序或建議修正。相似的介面用語，可能隱藏不同責任及不同驗證方法。
有意義的評估應比較相關變更的實際結果。審核者需要知道，某項發現是否指出真實問題、其解釋是否易於理解，以及其建議回應是否有效。即使三者同時出現在同一則留言中，仍是各自獨立的判斷。
AI Scan 與 CodeQL 的比較亦必須保留偵測與強制執行之間的分別。一項提供資訊的發現可以協助審核者，而毋須成為自動合併條件。只要團隊明白其工作流程的要求，這種安排可以很有用。
GitHub 整合的優勢在於訊號出現的位置：開發人員在檢視擬議程式碼時便會遇到它。餘下的是證據責任：團隊必須決定該發現值得多大信心，並記錄最終採取的行動。
建議性發現將發佈決定留給人員
若團隊希望不能阻止合併的警告影響發佈決定，就需要明確的人為回應。
GitHub 清楚界定了執行邊界。AI 發現不會令程式碼掃描檢查失敗，亦不能透過儲存庫 ruleset 要求阻止合併。Rulesets 是定義接受變更條件的儲存庫政策。
這個界線可避免團隊把發現項目的出現，等同於自動停止發佈。警告可以維持可見，同時建議的變更仍可合併。人工審核人員必須決定是否要求修正、尋求進一步分析，或接受餘下風險。
諮詢式運作帶來實際好處。團隊可檢視新的發現來源，而毋須將每個存疑結果都變成自動中斷。這讓團隊可在賦予該訊號更重要的內部決策角色前，先評估其實用性。
相應的風險是責任歸屬不清。若開發人員以為安全團隊會回應，而安全團隊又以為開發人員負責審核，顯眼的警告便可能得不到實質評估。單靠介面無法填補這個責任缺口。
GitHub 的 AI Scan 限制亦區分了建議變更與歷史覆蓋範圍。此功能不支援完整儲存庫掃描。其發現會保留在 pull request 中，而不會在儲存庫安全檢視中顯示為待辦警示。
待辦警示是會持續追蹤、留待日後修復的問題。當工作延續至原有審核以後，這個區別尤其重要。若某項疑慮需要在即時討論結束後繼續調查，團隊便需要有意識地交接。
文件承認會出現誤報，即在沒有問題的地方識別出問題的發現。這正是應要求調查、而非自動接受的理由。這並不代表某個特定發現必定錯誤，亦不代表整項功能沒有價值。
建議修正引入了相關的判斷問題。某項修改可能移除可疑模式，同時改變預期行為。即使建議的修補程式看來精簡，審核人員仍應分別評估背後的安全論據及功能後果。
不妨考慮一個說明性的警告：某個部署指令碼接受外部輸入。重要問題是該輸入是否以危險形式到達某項操作。一個有說服力的解釋應協助審核人員追蹤這段關係，而非僅僅將操作標示為可疑。
建議的修正方案之後亦需要獨立評估。它是否適當地限制輸入？是否保留合法的部署行為？周邊流程是否仍能運作？無論由哪一個工具提出建議，這些問題仍然重要。
發佈資料未有提供獨立的正面比較基準，以確立產品在所列技術中的偵測準確度。讀者應區分已確認的可用性與已記錄的行為，以及尚未確立的效能主張。
這個驗證缺口不會抹煞公告的價值。它界定了恰當的結論：團隊擁有一個更廣泛的檢查選項，並有已記錄的限制。現有證據不足以支持在啟用後便宣稱其程式碼安全。
更多發現需要更好的成果衡量方式
發現數量描述活動；並不能證明團隊消除了多少安全風險。
GitHub 於 10 月 13 日在安全總覽中推出 AI Scan 指標。公開預覽版包括已產生及已解決的發現、修復率、儲存庫趨勢，以及 autofix 建議的使用情況。它將 AI Scan 與 CodeQL 報告分列於不同分頁。
這些衡量方式為管理員評估部署提供起點。它們有助揭示發現在哪裏出現，以及開發人員是否作出回應。它們亦為跨專案比較審核行為提供基礎，而毋須逐一閱讀每段討論。
解讀這些數字仍需審慎。更多發現可能反映檢查範圍擴大、更多符合資格的變更，或不同的程式碼組合。較高的總數本身不能證明偵測能力更佳，亦不能證明應用程式安全性正在惡化。
解決狀態同樣是需要背景的成果。評估成效的團隊應了解其記錄狀態在實際運作上的含義。重要問題是已確認的疑慮是否得到充分回應，而非儀表板上的數字是否下降。
接受 autofix 是開發人員互動的有用證據，但不足以證明獲接受的變更已完整處理風險。負責任的評估應把獲接受的建議，與審核人員的推理及相關驗證連繫起來。
同樣地，低回應率在作出判斷前需要調查。審核人員可能正在拒絕不準確的發現、延後困難的修正，或忽略留言。同一個可見指標可反映不同的底層情況。
這正是部署可產生超越即時發現的知識之處。審核討論會揭示有關應用程式邊界、部署假設及責任歸屬的重複誤解。保留這些決定有助日後審核人員避免重複進行同樣的調查。
對於記錄這些背景的團隊而言，一個可搜尋的知識庫可支援存取技術文件及過往推理。有用的內容是決策背後的解釋，包括其假設及驗證。一系列未經解釋的警示標題幫助較少。
財務評估應與營運評估並列。相關比較包括掃描用量，以及作出決定所需的人力工作。能產生有用發現的工具仍需要審核能力，而嘈雜的部署則可能消耗注意力，卻不會改善決策。
因此，一份有參考價值的內部報告，應把產品活動與一小組已審核的例子連繫起來。它應展示功能揭示了甚麼、審核人員為何接受或拒絕該項疑慮，以及之後發生了甚麼。這讓結論可供評估。
此方法亦可防止誇大成功。團隊可以承認有用的偵測，同時記錄覆蓋範圍或工作流程中尚未解決的弱點。正式推出代表產品已發佈；經證明的價值則來自實際審核中的結果。
留意驗證、覆蓋範圍變更及開發人員的後續行動
下一項有用證據涉及偵測品質、覆蓋範圍邊界，以及審核人員是否將發現轉化為有理據的行動。
首個值得留意的訊號，是採用清楚說明的測試案例進行獨立驗證。評估應識別所檢視的技術、涵蓋的弱點，以及審核人員如何確立正確結果。它亦應區分真實的應用程式背景與孤立例子。
若證據顯示有用的偵測成果，而所需審核工作可管理，便會加強擴大採用的理據。若證據顯示持續不準確或遺漏重要案例，便會削弱人們對受影響用途的信心。兩種結論都不應自動延伸至每項受支援技術。
有用的評估應包括不成功的案例，而非只展示具說服力的示範。讀者需要了解引擎在哪些地方有幫助，以及在哪些地方仍存在不確定性。透明呈現限制，可讓結果更有助決定哪些儲存庫應優先處理。
第二個訊號是覆蓋範圍或執行邊界的已記錄變更。Fork 貢獻、相依套件更新請求、完整儲存庫分析及合併強制執行，都是不同能力。日後其中一個範疇的擴展，不應被解讀為所有範疇均已擴展。
例如，更廣泛的貢獻覆蓋範圍，會對審核流量來自外部副本的維護者產生影響。持續問題追蹤則處理另一個問題：在原有審核結束後，仍讓疑慮保持可見。每項變更都會改變工作流程中不同的一環。
任何未來的強制執行功能都值得特別仔細審視。讓某項發現符合阻止合併的資格，會改變其營運後果。團隊需要清晰的設定控制，以及支持其賦予該決定信心程度的證據。
第三個訊號是初步推出後，開發人員能否持續跟進。管理員應超越早期的新鮮感，了解發現是否持續獲得實質回應。最有力的證據會把警告與已確認的疑慮、已審核的變更及適當驗證連繫起來。
若團隊持續記錄有用的發現及已完成的修正，便會加強保留額外檢查的理據。若發現持續累積而責任歸屬不清，產品的可見度便會超過其營運影響。單靠儀表板無法判定這個區別。
在未來數月，這些訊號應會比圍繞 AI 品牌建立的功能比較，提供更有用的圖像。GitHub AI Scan 在擴展檢查方面有明確角色。它的實際貢獻取決於其證據能否經得起審核。
在擴大採用前，選擇一組具代表性的合資格儲存庫，並檢視由此產生的決定。問問哪些發現識別出真實疑慮、哪些解釋有所幫助，以及哪些建議變更通過測試。將排除項目及延後工作與成功修正一併記錄。將審核人員投入的工作，與已確認問題的價值作比較，而非慶祝持續上升的警示總數。在評估新增證據期間，維持現有安全控制。然後隨著驗證及覆蓋範圍改變，再次檢討推出安排。對你的團隊而言，額外檢查會帶來更清晰的安全決策，還是只留下更多等待有人負責的警告？
