12 篇文章 含有標籤「Cloud」

🤖 GitHub Copilot如何提升無障礙治理流程效率​

Source: https://github.blog/ai-and-ml/github-copilot/how-we-automated-accessibility-compliance-in-five-hours-with-github-copilot/

• GitHub 推出無障礙治理計畫，但面臨服務擁有者延遲處理無障礙修復工作的挑戰。
• 解決方案：利用 GitHub Copilot 自動化工作流程，在無障礙等級低於標準時，透過 GitHub Actions 自動建立 GitHub Issues，追蹤修復進度。
• 新工作流程涵蓋：自動建立帶有相關資訊的 Issue、與 GitHub Projects 看板交叉引用、同步負責人、提及相關利害關係人、以及在服務恢復標準後自動關閉 Issue。
• Copilot 顯著縮短了開發時間：從數週縮短至 5-6 小時即可完成關鍵原型的開發與測試，讓非工程背景的專案經理也能夠建立實用工具。
• 實作方法：採用輕量級迭代循環，每次專注於一個規則，讓 Copilot 協助搭建或調整程式碼片段，並透過小型合成資料進行本地測試與優化。
• 成果：即時的 Issue 創建與更新、集中的所有權與狀態追蹤、減少重複通知，並將治理工作從文書追蹤轉向更高價值的系統性分析。

如何利用 GitHub Copilot 在五小時內自動化實現無障礙合規性 🧑‍💻​

Source: https://github.blog/ai-and-ml/github-copilot/how-we-automated-accessibility-compliance-in-five-hours-with-github-copilot/

• GitHub 過去的無障礙合規修復流程是手動且效率低下，導致反應時間慢、追蹤不一，且無法規模化。
• 透過 GitHub Copilot，團隊在約五到六小時內，將此流程轉變為自動化、可審計的循環，包括自動建立 GitHub Issues、更新現有問題、交叉引用 CRM 追蹤、自動關閉已解決的問題、同步指派者及提及相關利害關係人。
• Copilot 透過快速原型設計和測試，讓領域專家直接構建自動化解決方案，大幅減少傳統開發所需的數週時間，將工程師從基礎骨架工作解放，專注於安全、規模化與生產強化。
• 建構流程輕量化，包括：用簡潔語言定義規則、請 Copilot 調整程式碼而非從零開始、使用小型合成數據測試邏輯、審查輸出並優化提示、添加防護措施（如冪等性、減震機制）、記錄決策並重新運行測試以確保無回歸。
• 自動化成果包括：修復問題迅速出現、所有權和狀態集中化、減少重複或過時的溝通、治理工作轉向高價值分析。Copilot 的賦能讓領域專家能夠直接構建原型，降低了未來合規工具的開發門檻。

GitHub SSH 存取引入後量子安全 🔒​

Source: https://github.blog/engineering/platform-security/post-quantum-security-for-ssh-access-on-github/

• GitHub 將為其 SSH 端點新增一個後量子安全 SSH 金鑰交換演算法：sntrup761x25519-sha512（或 [email protected]）。
• 此變更僅影響 SSH 存取，對 HTTPS 存取無影響，也不影響位於美國地區的 GitHub Enterprise Cloud 資料駐留。
• 目的是防範未來量子電腦可能進行的「先儲存，後解密」攻擊，確保資料的長期安全。
• 採用混合式方法，結合了 Streamlined NTRU Prime（一種新的後量子安全演算法）與經典的 Elliptic Curve Diffie-Hellman（使用 X25519 曲線），確保安全性不低於經典演算法。
• 此演算法將於 2025 年 9 月 17 日起在 GitHub.com 和非美國地區的 GitHub Enterprise Cloud 上啟用，並將包含在 GitHub Enterprise Server 3.19 中。
• 大多數現代 SSH 客戶端（例如 OpenSSH 9.0 或更新版本）將自動選擇新演算法，無需手動配置；舊版客戶端將回退到舊演算法。
• 您可以透過執行 ssh -Q kex 來檢查 SSH 客戶端是否支援此演算法，並使用 ssh -v [email protected] exit 2>&1 | grep 'kex: algorithm:' 來查看連接 GitHub 時所使用的金鑰交換演算法。

🚀 如何使用 Playwright MCP 和 GitHub Copilot 偵錯 Web 應用程式​

Source: https://github.blog/ai-and-ml/github-copilot/how-to-debug-a-web-app-with-playwright-mcp-and-github-copilot/

• Playwright Model Context Protocol (MCP) server 結合 GitHub Copilot 可自動化 Web 應用程式的錯誤重現、驗證與修復過程，解決許多專案缺乏完善測試的痛點。
• Playwright 是一個用於 Web 應用程式的端到端測試框架，而 MCP 則是由 Anthropic 開發的開放協議，旨在將工具暴露給 AI 代理。Playwright MCP Server 允許 Copilot 建立並執行這些自動化腳本。
• 在 VS Code 中配置 Playwright MCP server 需在 .vscode/mcp.json 中添加以下配置，使其可供所有專案使用：

  {
    "servers": {
      "playwright": {
        "command": "npx",
        "args": [
          "@playwright/mcp@latest"
        ]
      }
    }
  }
  

• GitHub Copilot agent mode 能夠根據錯誤報告的重現步驟，利用 Playwright MCP server 自動執行測試、確認問題、追蹤並解決錯誤，甚至在提出修復方案後，返回 Playwright 驗證其有效性。
• 透過 Playwright，Copilot 能「看到」其更改對網站的影響，這對於處理更複雜的錯誤尤其寶貴，顯著提升了偵錯效率。

🤔 重新發掘學習的樂趣：Jason Lengstorf 談開發現況​

Source: https://github.blog/developer-skills/career-growth/rediscovering-joy-in-learning-jason-lengstorf-on-the-state-of-development/

• 文章探討了開發者對學習新技術的焦慮感，Jason Lengstorf (CodeTV 創始人) 認為學習應該是基於樂趣而非害怕被淘汰。
• AI 作為能力乘數而非取代者：AI 能顯著提升熟練開發者的速度，並加速初學者的學習過程。但若缺乏學習意願，AI 反而會製造更大的問題。
• 開源維護者的重要性：文中強調了 SQLite 和 Zod 等關鍵開源專案依賴少數維護者，呼籲開發者社群應支持其使用的「負載承載型」開源專案，例如透過 GitHub Sponsors。
• 未來網頁創新的趨勢：JavaScript 生態系目前處於停滯期，而 CSS 則蓬勃發展。Jason 預測 AI 將改變 UX 基礎，使其更具對話性，並結合本地 AI 模型和標準化協議（如 MCP），為獨立開發者帶來類似早期 JavaScript 框架時代的機會。

🌍 誰將維護未來？為新一代重新思考開源領導力​

Source: https://github.blog/open-source/maintainers/who-will-maintain-the-future-rethinking-open-source-leadership-for-a-new-generation/

• 開源社群「老齡化」問題： 根據 Tidelift 2024 年維護者調查，46-65 歲維護者的比例自 2021 年以來翻了一倍，而 26 歲以下貢獻者則從 25% 下降到 10%。這揭示了開源社群面臨的傳承危機和潛在的知識流失。
• Gen Z 貢獻者「Sam」視角： 文章引入一位 23 歲 Gen Z 貢獻者「Sam」的人格設定，他們渴望為有意義的氣候科技專案貢獻，透過 YouTube 自學程式碼，擅長線上社群管理，但對公開儲存庫感到畏懼。他們尋求目標、彈性及歸屬感。
• 「參與之山」框架： 為了幫助像 Sam 這樣的貢獻者茁壯成長，文章提出一個包含六個階段的框架：「參與之山」——發現、首次接觸、參與、持續參與、網絡參與、領導力。
• 針對 Gen Z 需求調整傳統最佳實踐：
  • 發現階段： Gen Z 透過 TikTok、Discord 和 YouTube 發現專案，他們希望在 README 中直接看到專案宗旨，並偏好行動裝置學習。專案需在 Gen Z 活躍的平台露面。
  • 首次接觸： 需提供行動友善、視覺優先的登陸體驗，以及像 Discord 這樣輕鬆開放的聊天頻道，讓新手可以潛水觀察。
  • 參與階段： Gen Z 偏好即時回饋、沙盒環境進行嘗試，以及提供允許學習而非僅限展示的空間，例如 FreeCodeCamp 和 Kubernetes 的貢獻者遊樂場模式。
  • 持續參與： 重視可分享的認可（徽章、提及、作品集），更關注影響力而非層級晉升。
  • 網絡參與： 偏好具名的、可分享的角色（如 Discord 版主、社群嚮導），非正式交流，以及同儕主導的領導模式（如 Rust 的共識驅動治理）。
  • 領導階段： 期望共同管理而非自上而下的控制，並尋求補償或專業成長，例如 TensorFlow 的貢獻者階梯。
• 具體行動建議： 將 README 轉化為 60 秒解說影片、建立首次貢獻者的沙盒空間、啟動 Discord 或非主題頻道以培養歸屬感、明確並公開專案使命。

🔒 Docker @ Black Hat 2025：CVE 漏洞應對之道​

Source: https://www.docker.com/blog/docker-black-hat-2025-secure-software-supply-chain/

• 在 Black Hat 2025 大會上，CVE 漏洞成為核心議題，業界正從被動掃描轉向主動在軟體供應鏈源頭消除安全負債。
• 前進方向包括：使用強化版映像 (Hardened Images)、符合法規的工具以及強大的生態系合作夥伴關係 (如 Docker 與 Wiz)。
• 會議指出六大安全主題，強調掃描不足以應對，需要「零 CVE」的起始點，並透過提供 Debian 和 Alpine 等不同發行版，以及靈活的客製化能力來滿足企業需求。
• Docker Hardened Images (DHI) 提供零 CVE 的基礎映像，並附帶 SLA、SBOM (軟體物料清單) 和簽名證明，消除安全性與易用性之間的權衡。
• 即使是新興的 AI 工作負載，也能受益於既有的容器安全模式（隔離、閘道控制、執行前驗證），DHI 作為 AI 系統的可信啟動平台至關重要。

🔗 大規模保障供應鏈安全：從 71 個重要開源專案做起​

Source: https://github.blog/open-source/maintainers/securing-the-supply-chain-at-scale-starting-with-71-important-open-source-projects/

• Log4j 零日漏洞事件後，凸顯了開源庫安全性對整個軟體供應鏈的巨大影響，促使 GitHub 於 2024 年 11 月啟動「GitHub 安全開源基金」（GitHub Secure Open Source Fund）。
• 該基金為維護者提供資金支援，參與為期三週的專案，內容包含安全教育、導師指導、工具、認證及安全意識社群等，旨在提升安全影響力、降低風險，並大規模保護軟體供應鏈。
• 前兩期專案已集合來自 71 個重要開源專案的 125 位維護者，取得了顯著成果：
  • 修復了 1,100 多個由 CodeQL 檢測到的漏洞。
  • 發布了 50 多個新的常見漏洞與暴露（CVE），保護下游依賴項。
  • 阻止了 92 個新機密洩漏，並檢測和解決了 176 個已洩漏的機密。
  • 80% 的專案啟用了三個或更多基於 GitHub 的安全功能，63% 的專案表示對 AI 和 MCP 安全有更好理解。
  • 維護者利用 GitHub Copilot 進行漏洞掃描、安全審計、定義和實施模糊測試策略等。
• 專案涵蓋了 AI/ML 框架（如 Ollama, AutoGPT）、前端/全端框架（如 Next.js, shadcn/ui）、Web 伺服器/網路/閘道（如 Node.js）、DevOps/建置工具（如 Turborepo）、安全框架/身份/合規工具（如 Log4j）、以及開發者工具/CLI 助手（如 Charset-Normalizer, nvm, JUnit）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

🔒 每個人都是「雪花」：為真實世界設計強化映像檔流程​

Source: https://www.docker.com/blog/hardened-image-best-practices/

• 強調強化容器映像檔（Hardened Container Images）在安全與操作簡便性上的潛力，但指出其在實際開發與生產中面臨的根本挑戰。
• 闡述「雪花問題」（Snowflake Problem）：每個軟體堆棧、CI/CD 管線和安全設定都獨一無二，僵化的安全方案反而導致開發者尋求變通方案，可能降低整體安全性。
• 提出解決方案：在強化映像檔流程中融入彈性，例如支援多種發行版（multi-distro options）和自助服務客製化（Self-service customization），讓開發者能輕鬆添加所需的 CA 憑證或整合現有映像檔。
• 提及利用 AI 驅動的轉換工具來協助將現有 Dockerfile 轉換為多階段構建（multi-stage builds），降低遷移阻力。
• 強調社群信任的重要性：與開源專案維護者建立緊密關係，確保強化映像檔的設計能納入專案見解與經驗。
• 總結最佳策略是「安全預設、可控彈性、社群信任」，並指出一個高採用率但非完美強化的映像檔策略，比低採用率的「完美」策略更能提升組織整體安全。

這份摘要聚焦於最新的雲端與人工智能技術趨勢，尤其是 Docker 在代理應用、AWS 的結合應用、以及數據分析、安全規範等方面的創新與實務案例。內容涵蓋從代理應用開發生態、雲端事故調查整合、到資料分析在醫療領域的實務挑戰，提供完整的技術洞見與實務流程。

Docker 推動代理應用的未來 🚀​

Source: https://www.docker.com/blog/wearedevelopers-docker-unveils-the-future-of-agentic-apps/

• Docker在WeAreDevelopers會議展示支持代理應用的工具進展，代理應用定義為利用LLMs來構建以目標為導向，具備訪問工具、資料和系統的應用。
• 代理應用的棧中，Docker支持模型下載執行、容器化的工具伺服器，以及用compose.yaml整合模型、工具及自定義代碼。
• 以範例compose文件整合模型、MCP Gateway與應用，支持多框架（如ADK、CrewAI）並支持雲端部署（Google Cloud Run、Azure）。
• Docker推出Compose for agents、支援Google原生Cloud Run部署、Docker Offload（雲端GPU資源調度）來降低模型部署門檻。
• 大型Workshop及Lightning Talks促進社群交流與實務應用，並宣布2026年的WeAreDevelopers北美盛會。

重點： 代理應用將成為AI應用新生態的核心，Docker提供全方位工具支持開發到部署，並強調雲端資源整合。