60 篇文章 含有標籤「AI」

🔒 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 系統的可信啟動平台至關重要。

GPT-5 在 GitHub Copilot：我如何在 60 秒內建構一款遊戲 🚀​

Source: https://github.blog/ai-and-ml/generative-ai/gpt-5-in-github-copilot-how-i-built-a-game-in-60-seconds/

• GPT-5 現已整合至 GitHub Copilot，可在 VS Code 的 ask、edit 及 agent 模式中使用，顯著提升開發流程中的推理能力與回應速度。
• 啟用方式簡單，僅需在 Copilot 介面中開啟模型選擇器並選取 GPT-5 即可。企業用戶需經管理員啟用。
• 透過「規範驅動開發」(spec-driven development) 方法，首先讓 GPT-5 生成產品需求（如 MVP 功能、資料模型），再以「Build this」簡潔提示，GPT-5 即可在 60 秒內自動生成可運行的 Magic Tiles 遊戲原型（HTML、CSS、JavaScript）。
• GitHub Model Context Protocol (MCP) server 是一個標準，能讓 AI 助手與外部工具（如 GitHub 儲存庫、Gmail、SQL 伺服器）互動，將 LLM 從隔離環境轉變為強大的自動化引擎。
• 設定 GitHub MCP 伺服器僅需不到 5 分鐘，透過在工作空間根目錄建立 .vscode/mcp.json 配置檔並進行 GitHub OAuth 驗證即可。
• 實際應用範例包含透過自然語言創建 GitHub 儲存庫及批量建立議題，大幅減少上下文切換，提高開發效率。
• 這個工作流程的優勢在於 GPT-5 的處理速度、上下文保留能力，以及將自然語言作為開發介面，同時保持「人機協同」的控制。

🚨 GitHub 2025 年 7 月可用性報告​

Source: https://github.blog/news-insights/company-news/github-availability-report-july-2025/

• GitHub 於 2025 年 7 月 28 日經歷了一次服務降級事件，導致 GitHub Enterprise Importer (GEI) 在約 5 小時 34 分鐘內無法處理遷移作業。
• 事件根源在於 GEI 基礎設施的一個組件在例行內部改進過程中被錯誤地移除服務，且無法恢復到先前的配置，需重新佈建資源解決。
• 為了解決此問題，GitHub 已識別並實施了基礎設施恢復、單元測試以及使用測試數據進行更好驗證的改進。
• 受影響的用戶需更新其 IP 允許清單，新增 GEI 的新 IP 範圍 20.99.172.64/28 和 135.234.59.224/28，並移除不再使用的舊 IP 範圍 40.71.233.224/28 和 20.125.12.8/29。

🌐 從私有到公開：聯合國組織如何分四步開源其技術​

Source: https://github.blog/open-source/social-impact/from-private-to-public-how-a-united-nations-organization-open-sourced-its-tech-in-four-steps/

• 聯合國專門機構國際電信聯盟電信發展局 (BDT) 透過 GitHub 技能志願項目，成功將其閉源的 Azure DevOps 環境轉型為開放源碼社群，以賦能全球合作夥伴。
• 對於聯合國組織和非營利組織，開源能有效應對預算有限和團隊規模小的挑戰，大幅擴大其影響力。
• 開源轉型分為四個關鍵步驟：
  1. 進行研究： 分析喜歡和不喜歡的開源儲存庫，學習其 README、貢獻指南和社群運作方式，參考 Ersilia 和 Terraform 等活躍社群範例。
  2. 優化開源心態與程式碼： 清理敏感信息、提供範例數據，並創建清晰的「入門指南」(Getting Started) 和 CONTRIBUTING.md 文件，確保有自動化測試以維持程式碼品質。
  3. 釐清授權方式： 使用 choosealicense.com 等資源選擇合適的開源許可證（如 ITU 選擇了 BSD-2 許可證），並確保與專案依賴項的兼容性。
  4. 與開源社群互動： 將專案中的「小問題」標記為 good first issue，吸引新貢獻者快速上手並熟悉程式碼庫。
• BDT 與 GitHub 的合作不僅提升了其開源專業知識，也為其開源未來奠定了堅實基礎。

🔗 為何 GitHub 開源 MCP 伺服器，以及這對您的意義​

Source: https://github.blog/open-source/maintainers/why-we-open-sourced-our-mcp-server-and-what-it-means-for-you/

• 當 LLMs（大型語言模型）缺乏外部工具和數據源的連接能力時，容易產生幻覺（hallucinations），給出看似合理但錯誤的答案。
• Model Context Protocol (MCP) 是一個開放協議，旨在標準化 LLM 應用程式如何連接並使用外部工具和數據源，其角色類似於程式語言伺服器協議 (LSP) 之於程式語言，可以視為「LLM 的 LSP」。
• GitHub 已開源其 MCP 伺服器，作為 GitHub 平台與任何 LLM 之間的「真相來源」介面，有助於減少幻覺並啟用新的自動化工作流程。
• GitHub 的 MCP 伺服器允許使用者以自然語言發出請求（例如「列出所有開放的議題」），這些請求會被自動轉換為結構化、語義豐富的 API 調用，從而獲取 GitHub 上的即時數據。
• 該架構概念上簡單但功能強大，將語言模型、用戶體驗和數據/工具訪問分離，使每一層都模組化、可測試和可替換。
• 要在 VS Code 中使用 GitHub MCP 伺服器，需添加以下設定並完成 OAuth 流程：

  {
    "servers": {
      "github": {
        "type": "http",
        "url": "https://api.githubcopilot.com/mcp/"
      }
    }
  }
  

• 實際應用案例包括：將 GitHub Issues 自動轉換為 Markdown 內容文件、編譯每週團隊摘要的輕量級機器人、基於聊天的專案助手，以及個人化的 LLM 儀表板，這些都證明了 MCP 伺服器透過提供真實、結構化的上下文，使 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）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

Remocal 與最小可行模型：為何適尺寸模型優於 API 過度依賴 🚀​

Source: https://www.docker.com/blog/remocal-minimum-viable-models-ai/

• AI API 使用的痛點： 傳統上過度依賴大型 AI API 導致企業面臨每月數百至數萬美元的高昂成本、高達 2-3 秒的響應延遲、敏感資料的隱私與合規性問題，以及開發者受限於龐大遠端模型的窘境。例如，一個簡單的情緒分析器每月可能花費 $847，一個聊天機器人則可能高達 $15,000。
• Remocal 混合開發策略： Remocal (remote + local) 是一種結合本地開發與雲端資源的混合方法。它允許開發者在本地使用較小型模型進行快速迭代與測試，並在 AI 應用場景或工作負載超出本地能力時，無縫地擴展到雲端 GPU 資源，解決了傳統開發中部署摩擦大、雲端管理複雜等問題。
• 最小可行模型 (Minimum Viable Model, MVM) 的概念： MVM 指的是部署能夠有效解決核心業務問題的最小、最有效率的模型。將 MVM 與 Remocal 方法結合，意味著可以首先在本地使用輕量級模型進行開發，僅在絕對必要時才調用更強大的雲端模型或運算資源，從而極大降低成本並加速開發迭代。
• 適尺寸模型技術突破： 許多創新技術讓模型在縮小體積的同時仍能保持高性能，使得 MVM 策略更加可行：
  • 策展資料小型語言模型 (SLMs)： 例如 Microsoft 的 Phi-4 系列，透過精心篩選的高品質訓練資料，使參數小於 15B 的模型在語言、編碼和數學基準上媲美甚至超越大型模型，大幅降低記憶體與延遲需求。
  • 量化 (Quantization)： 將模型權重壓縮至 4-bit 塊，並搭配低秩適配器層，可減少約 75% 的 GPU RAM 使用量，同時僅損失約 1% 的準確度，使筆記型電腦也能執行訓練或推論。
  • 稀疏專家混合 (Sparse Mixture-of-Experts, MoE)： 如 Mistral 的 Mixtral 8x7B，每次推論只啟用少於 25% 的參數，但性能可與密集型模型匹敵，有效降低服務成本。
  • 記憶體高效注意力核心 (Memory-efficient attention kernels)： 如 FlashAttention-2，透過優化讀寫，使注意力機制更適合片上 SRAM，倍增吞吐量並允許在普通 GPU 上處理更大上下文。
  • 設備端「奈米」模型 (On-device “nano” models)： 如 Google Gemini Nano 直接嵌入 Chrome 和 Android，證明參數小於 4B 的模型能在手機和瀏覽器上實現隱私、低延遲的本地推論。
• MVM 友善的生產就緒模型範例： 許多模型已針對高效能和低資源消耗進行優化：
  • Microsoft Phi-4 (14B)： 透過高度策展的訓練資料，在複雜推理、數學和編碼任務上表現優異，能以 4-bit 量化在 10-15GB VRAM 的環境下運行，性能超越大型模型。
  • Gemma 3 (27B)： 支援多模態與多語言，利用優化的量化技術，能在單一 RTX 3090 或 H100 GPU (約 7GB VRAM) 下提供與大型模型接近的性能。
  • SmolLM3 (3B)： 具雙模式推理、多語言及長上下文處理能力，僅需約 6GB VRAM，可在筆記型電腦或邊緣設備上運行，展現出超越其體積的強大效能。
• 選擇模型準則：
  • 何時選擇 API 模型： 當您需要廣泛的世界知識、複雜的多步驟跨領域推理、構建通用對話 AI、每月請求量少於 1,000 次，或 2-5% 的準確度提升能合理化 100 倍的成本時。
  • 何時選擇適尺寸模型： 當您的任務明確（如分類、程式碼補全、文件處理）、需要一致的低延遲響應、每次推論成本對業務模式至關重要、有資料隱私或合規性要求，或希望擺脫 API 速率限制時。大多數生產 AI 應用屬於此類，適尺寸模型能以極小成本提供接近大型模型的性能，同時具備更高的開發速度、靈活性和安全性。

🚀 提升程式碼審查與 Pull Request 效率：GitHub Copilot 的應用​

Source: https://github.blog/ai-and-ml/github-copilot/how-to-use-github-copilot-to-level-up-your-code-reviews-and-pull-requests/

• GitHub Copilot 的功能已從最初的程式碼補全，擴展到 Pull Request (PR) 和程式碼審查等多方面應用，有效提升開發工作流程效率。
• 在程式碼審查中，可利用 Copilot 建議程式碼改進或確認是否符合最佳實踐，例如重構重複的 Ruby on Rails 程式碼或檢查 Go 語言變數賦值的最佳實踐。

  "Can you refactor this Ruby on Rails code to reduce repetition?"
  

  "Is this code addition following Go best practices for variable assignment? If not, can you suggest improvements?"
  

• Copilot 能夠協助將原始資料（如試算表中的載入時間數據）格式化為 GitHub 風格的 Markdown 表格，使 PR 說明更加清晰易讀。

  Load Time Before (in seconds)   Load Time After Updates (in seconds)
  1.3 1.2
  1.2 1.1
  1.1 0.885
  1.3 1.3
  1.2 0.918
  
  Average 1.22    1.0806
  

  Copilot 輸出範例：

  | Test Run | Load Time Before (seconds) | Load Time After Updates (seconds) |
  |----------|---------------------------|-----------------------------------|
  | 1        | 1.3                       | 1.2                               |
  | 2        | 1.2                       | 1.1                               |
  | 3        | 1.1                       | 0.885                             |
  | 4        | 1.3                       | 1.3                               |
  | 5        | 1.2                       | 0.918                             |
  | **Average** | **1.22**                  | **1.0806**                         |
  

• Copilot 可為 Pull Request 摘要提供撰寫起點，即使需要編輯，也能有效降低撰寫門檻。
• 開發者可利用 Copilot 進行初步的程式碼審查，找出潛在問題或提供更好的撰寫方式；同時也能請求 Copilot 解釋不熟悉的程式碼，加速理解並提供更周全的審查意見。

🚀 初級開發者並未過時：如何在 AI 時代蓬勃發展​

Source: https://github.blog/ai-and-ml/generative-ai/junior-developers-arent-obsolete-heres-how-to-thrive-in-the-age-of-ai/

• 人工智慧並不會讓初級開發者過時；相反地，新進學習者因具備 AI 工具的應用能力，反而處於有利位置。
• GitHub 執行長 Thomas Dohmke 強調，熟悉 AI 程式碼生成工具的新人才，能帶來更好的想法。
• 提供初級開發者在 AI 時代脫穎而出的五種方法：
  1. 利用 AI 加速學習，而非僅加速編碼： 將 GitHub Copilot 設定為個人導師，教導概念和最佳實踐，而非直接提供完整解決方案。可以透過 VS Code 命令面板運行 Chat: New Instructions File 並貼上以下指令：

     ---
     applyTo: "**"
     ---
     I am learning to code. You are to act as a tutor; assume I am a beginning coder. Teach me concepts and best practices, but don’t provide full solutions. Help me understand the approach, and always add: "Always check the correctness of AI-generated responses."
     

     此外，練習在不使用自動完成功能的情況下解決問題（可透過在專案根目錄 .vscode/settings.json 中設定 {"github.copilot.enable": {"*": false}} 來禁用）。
  2. 建立公開專案以展示技能（和 AI 熟練度）： 利用 GitHub Copilot Chat 的 /new 指令來啟動新專案，並使用以下 Git 命令將其發布：

     git init && git add . && git commit -m "Initial commit" && git push
     

  3. 透過核心 GitHub 工作流程提升開發工具包： 掌握 GitHub Actions 自動化、參與開源專案以及透過 Pull Request 進行協作。Copilot Chat 可協助排除故障。
  4. 透過程式碼審查磨練專業知識： 積極提問、尋找模式、做筆記並保持謙遜。
  5. 運用 AI 更智慧、更快速地除錯： 使用 Copilot Chat 指令如 /fix、/tests、/explain 和 /doc 來即時解釋錯誤、生成修復方案、創建測試案例和理解根本原因。

加速 Docker 強化映像的 FedRAMP 合規性 🚀​

Source: https://www.docker.com/blog/fedramp-compliance-with-hardened-images/

• FedRAMP 合規挑戰： 聯邦風險與授權管理計畫 (FedRAMP) 合規成本高昂（45 萬至 200 萬美元以上），且需耗時 12 至 18 個月，這期間競爭對手可能已搶佔政府合約。企業需面對 NIST SP 800-53 中超過 400 項嚴格的安全控制要求。
• Docker 強化映像 (DHI) 解決方案： Docker 硬化映像提供自動化、可稽核的安全解決方案，旨在加速 FedRAMP 合規流程並降低維護成本。DHI 是一系列精簡的映像，持續更新以確保幾乎沒有已知的 CVE。
• FIPS 140 合規性： DHI 支援 FIPS 140 驗證的密碼學模組，預配置並經過測試，可確保正確功能。每個 FIPS 合規映像都附有簽名的證明，列出使用的 FIPS 驗證軟體及其 CMVP 認證和測試結果連結，支援 OpenSSL、Bouncy Castle 和 Go 等主要開源密碼學模組。
• STIG 強化映像： Docker 根據國防信息系統局 (DISA) 發布的通用作業系統 (GPOS) SRG，創建了客製化的容器 STIG。STIG 強化映像在安全建構過程中會使用 OpenSCAP 進行掃描，結果會作為簽名證明提供，其中包含易於查看的 STIG 合規分數，並支援輸出為 HTML 和 XCCDF 格式，便於稽核。
• 持續合規性：
  • 漏洞減少： DHI 起始攻擊面減少高達 95%（按包數量計算），持續更新以確保幾乎沒有已知 CVE，並掃描病毒和機密。
  • 漏洞檢測與修復： Docker 持續監控 CVE 來源，DHI 對嚴重/高風險漏洞的修復 SLA 為 7 天，中/低風險為 30 天，幫助滿足 FedRAMP 修復時限。提供 VEX (Vulnerability Exploitability eXchange) 證明來過濾不適用漏洞。
  • 供應鏈透明度： DHI 使用 SLSA Build Level 3 安全建構管道，確保建構可驗證性與防篡改。提供簽名證明和多種 SBOM 格式。
  • 稽核證據： DHI 證明符合 in-toto 證明標準，作為 provenance、資產管理、漏洞掃描及 FIPS 合規性的安全證據。

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

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），降低遷移阻力。
• 強調社群信任的重要性：與開源專案維護者建立緊密關係，確保強化映像檔的設計能納入專案見解與經驗。
• 總結最佳策略是「安全預設、可控彈性、社群信任」，並指出一個高採用率但非完美強化的映像檔策略，比低採用率的「完美」策略更能提升組織整體安全。