GitHub Copilot C++ 現代化工具正式上線，三階段 AI 工作流程自動升級 MSVC
Microsoft C++ 部落格 · 2026-06-12
背景
GitHub Copilot 現代化工具（Modernization for C++）自 Visual Studio 2026 版本 18.7 起正式脫離預覽，開放所有具備 Copilot 訂閱的開發者使用。此工具以 AI 代理形式整合於 Visual Studio，協助團隊將 C++ 專案升級至較新的 MSVC Build Tools 版本，目標是減少手動移植作業中耗時的錯誤排查。使用者可在 Solution Explorer 右鍵選擇「Modernize」，或在 Copilot Chat 視窗輸入 @Modernize 啟動代理。支援的專案類型包含 MSBuild 格式（.sln、.vcxproj）以及 CMake 專案。
核心改動
代理執行三階段工作流程：Assessment（評估）掃描專案並產生 assessment.md；Planning（規劃）轉化為 plan.md，記錄升級策略與風險緩解方案；Execution（執行）依序套用修正並驗證每個變更。所有狀態檔案存放於 .github/upgrades/{scenarioId}，支援中途關閉 Visual Studio 後繼續作業。相較預覽版，正式版新增了三項改進：
- 更精確的範疇護欄：區分升級引入的問題與既有問題，避免代理過度修改。
- Automatic／Guided 雙模式：前者自動執行全部階段，適合結構單純的專案；後者在每個階段邊界暫停人工確認，適合大型升級。
- 自適應任務管理：升級途中發現新問題時可動態調整計畫，不需重新啟動工作流程。
影響範圍
使用前須安裝「GitHub Copilot modernization」選用元件，並持有 GitHub Copilot 訂閱（付費或免費方案均可）。對於 MSBuild 專案，當 Visual Studio 偵測到缺少目前使用的 MSVC 版本時，Setup Assistant 將自動引導開發者選擇安裝舊版工具鏈或以新版本重新定向。此功能目前僅支援 Windows 平台，CMake 場景需手動完成工具鏈切換後再執行代理。
目前工具僅覆蓋「MSVC Build Tools 升級」一項情境；Microsoft 表示未來計畫擴展更多現代化場景，開發者可至 Developer Community 提案或投票，加速優先順序排定。
原始來源：Microsoft C++ 部落格、官方文件總覽
Azure DevOps Server 六月安全性修補：端點認證標頭防護與 Proxy 請求限制
Azure DevOps 部落格 · 2026-06-11
漏洞機制
Microsoft 於 2026 年 6 月 11 日同步釋出兩個自架版本的安全性修補，分別為 Azure DevOps Server Patch 5 與 Azure DevOps Server 2022 Update 2 Patch 10。兩批修補均針對服務端點（service endpoint）認證流程中的安全性缺口：攻擊者可能藉由特定 HTTP 標頭或不受限制的 Proxy 請求，在端點認證過程中傳遞本不應被轉發的資訊，進而繞過預期的安全邊界。
Patch 10 在同一發行說明中同時列出兩項修補，說明為「改善服務端點安全性，限制不安全的 Proxy 請求」以及「新增防護機制，防止特定標頭在端點認證過程中被傳遞」；Patch 5 則僅包含後者。
受影響版本
| 版本 | 修補名稱 | 修補內容 |
|---|---|---|
| Azure DevOps Server（最新版） | Patch 5 | 防止特定標頭於端點認證時被傳遞 |
| Azure DevOps Server 2022 Update 2 | Patch 10 | 限制不安全 Proxy 請求 ＋ 端點認證標頭防護 |
本次修補未附帶 CVE 識別碼，但屬於主動防禦性強化。相較之下，2 月發布的 Patch 8 曾修補 CVE-2026-21512（跨站腳本漏洞），顯示 Microsoft 正持續加強對 CI/CD 基礎設施認證鏈的稽核力道。
修補與緩解
管理員可至 Azure DevOps Server 下載頁面取得安裝包，並於安裝後執行以下指令確認套用成功：
<patch-installer>.exe CheckInstallMicrosoft 建議所有自架部署客戶儘速套用最新修補，維持在最安全的版本。未列出受影響舊版本（如 Azure DevOps Server 2020 或更早）的使用者，應評估是否升級至受支援版本。
Cilium 如何鎖定 CI/CD 依賴：SHA 釘版、Renovate 冷卻期與 Go 模組 Vendoring
CNCF 部落格 · 2026-06-12
原本的問題
Cilium 是一個基於 eBPF 的 Kubernetes 網路與安全方案，擁有超過 2.4 萬顆 GitHub 星星。維護者 André Martins 與 Feroz Salam 在這篇 CI/CD 強化系列的第二篇中，指出三類主要攻擊向量：第三方 GitHub Actions 標籤被竄改、傳遞性依賴在執行期引入惡意程式碼，以及 Actions 表達式注入漏洞。這類攻擊可讓惡意程式碼悄然混入建置流程，影響下游大量使用者。
採用的方法
針對 GitHub Actions，Cilium 全面改為以 40 字元 commit SHA 釘定版本，取代可變的 tag 參考。容器映像同樣改用 @sha256: 摘要。此做法可防止上游標籤被攻擊者悄悄置換，確保每次執行的程式碼與審查時完全一致。
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2自動化更新方面，Cilium 以自架方式運行 Renovate bot，全域啟用 pinDigests: true，並設定 5 天冷卻期，讓社群有時間在套件被採用前發現受損版本。僅有通過審查的受信任依賴清單才允許自動合併，其餘皆需人工審查。
- Go 模組全數 Vendor 化並提交至倉庫，CI 驗證
go.mod、go.sum與vendor/三者一致，同時執行授權稽核，防止意外引入不相容授權的依賴。 - 使用 CodeQL 強制執行
actions/missing-workflow-permissions規則，並以 Actionlint 靜態分析工作流程語法與不安全模式，阻擋表達式注入攻擊。 - Runner 標籤改為固定版本（如
ubuntu-24.04），避免使用浮動的ubuntu-latest，消除標籤漂移帶來的不確定性。
實際效果
Vendoring 策略將信任決策從建置時期前移至程式碼審查，typosquatting 套件（拼字劫持）會以可見的 diff 形式出現，而非在建置期悄悄引入。維護者刻意選擇不 fork 第三方 Actions，認為維護 fork 同步的成本與錯過上游安全修補的風險，遠高於以 SHA 釘版提供不可變性保證的實際收益。
本文為 Cilium CI/CD 強化系列的第二篇；第一篇涵蓋存取控制，第三篇將探討憑證隔離、發布簽署與建置 attestation，為整個供應鏈安全形成閉環。
原始來源：CNCF 部落格、Cilium GitHub 倉庫