26 篇文章 含有標籤「Security」

🤖 GitHub Models 如何幫助開源維護者專注於核心工作​

Source: https://github.blog/open-source/maintainers/how-github-models-can-help-open-source-maintainers-focus-on-what-matters/

• 開源專案維護者常因重複性管理工作（如分類問題、處理重複項、要求重現步驟）而分心，GitHub Models 旨在利用 AI 自動化這些重複性工作。
• 透過 GitHub Models 結合 GitHub Actions，實現「持續 AI」(Continuous AI) 模式，提供自動化工作流程，例如自動問題去重、問題完整性檢查、垃圾郵件與低品質貢獻偵測、持續解決方案以及新貢獻者引導。
• 自動問題去重範例：

  name: Detect duplicate issues
  on:
    issues:
      types: [opened, reopened]
  permissions:
    models: read
    issues: write
  jobs:
    continuous-triage-dedup:
      if: ${{ github.event.issue.user.type != 'Bot' }}
      runs-on: ubuntu-latest
      steps:
        - uses: pelikhan/action-genai-issue-dedup@v0
          with:
            github_token: ${{ secrets.GITHUB_TOKEN }}
            # Optional tuning:
            # labels: "auto"          # compare within matching labels, or "bug,api"
            # count: "20"             # how many recent issues to check
            # since: "90d"            # look back window, supports d/w/m
  

• 問題完整性檢查範例：

  name: Issue Completeness Check
  on:
    issues:
      types: [opened]
  permissions:
    issues: write
    models: read
  jobs:
    check-completeness:
      runs-on: ubuntu-latest
      steps:
        - name: Check issue completeness
          uses: actions/ai-inference@v1
          id: ai
          with:
            prompt: |
              Analyze this GitHub issue for completeness. If missing reproduction steps, version info, or expected/actual behavior, respond with a friendly request for the missing info. If complete, say so.
              
              Title: ${{ github.event.issue.title }}
              Body: ${{ github.event.issue.body }}
            system-prompt: You are a helpful assistant that helps analyze GitHub issues for completeness.
            model: openai/gpt-4o-mini
            temperature: 0.2
        - name: Comment on issue
          if: steps.ai.outputs.response != ''
          uses: actions/github-script@v7
          with:
            script: |
              github.rest.issues.createComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                issue_number: ${{ github.event.issue.number }},
                body: `${{ steps.ai.outputs.response }}`
              })
  

• 建議維護者從一個工作流程開始，逐步擴展，並監控結果、根據專案語氣調整 AI 提示。

🚀 建立你的第一個 MCP 伺服器：如何用自訂功能擴展 AI 工具​

Source: https://github.blog/ai-and-ml/github-copilot/building-your-first-mcp-server-how-to-extend-ai-tools-with-custom-capabilities/

• Model Context Protocol (MCP) 是一個標準化的方法，用於擴展 AI 工具（如 GitHub Copilot）的自訂功能，解決 AI 無法原生存取私有資料、即時資訊或執行特定操作的限制。
• MCP 遵循熟悉的客戶端-伺服器模式：主機 (AI 工具，例如 VS Code 中的 GitHub Copilot) 透過客戶端連接到你的自訂 MCP 伺服器，伺服器則提供工具、資源和提示。
• 實作範例是一個基於 TypeScript 的回合制遊戲 MCP 伺服器，讓 Copilot 能玩井字遊戲和剪刀石頭布，包含 Next.js Web App/API、MCP Server 和共用程式庫。
• 設定 MCP 伺服器需在 VS Code 中透過 .vscode/mcp.json 檔案進行配置，例如：

  {
    "servers": {
      "playwright": { /* ... */ },
      "turn-based-games": {
        "command": "node",
        "args": ["dist/index.js"],
        "cwd": "./mcp-server"
      }
    }
  }
  

• MCP 的三個核心組成部分：
  1. 工具 (Tools)：定義 AI 可以執行的動作，包含名稱、描述和輸入 schema。例如，play_tic_tac_toe 工具的定義：

     {
       name: 'play_tic_tac_toe',
       description: 'Make an AI move in Tic-Tac-Toe game. IMPORTANT: After calling this tool when the game is still playing, you MUST call wait_for_player_move to continue the game flow.',
       inputSchema: {
         type: 'object',
         properties: {
           gameId: {
             type: 'string',
             description: 'The ID of the Tic-Tac-Toe game to play',
           },
         },
         required: ['gameId'],
       },
     }
     

     實際的遊戲邏輯由 MCP 伺服器執行，而非大型語言模型 (LLM)。
  2. 資源 (Resources)：提供 AI 獲取上下文的方式，通常帶有 URI 識別符（例如 game://tic-tac-toe/{Game-ID}）。資源 URI 可轉換為 API 呼叫以獲取資料：

     async function readGameResource(uri) {
       const gameSession = await callBackendAPI(gameType, gameId);
       if (!gameSession) {
         throw new Error("Game not found");
       }
       return gameSession;
     }
     

  3. 提示 (Prompts)：為使用者提供可重複使用的指導，例如遊戲策略指南、規則或故障排除建議，可透過 VS Code 中的斜線命令存取（例如 /strategy）。
• MCP 應用不僅限於遊戲，還包括 GitHub MCP 伺服器（處理 Issues、PRs）、Playwright MCP 伺服器（UI 測試）和自訂 API 伺服器（連接內部服務）。
• 實作時應考慮身份驗證、安全性，並對第三方 MCP 伺服器進行盡職調查，同時 MCP 提供多種語言的 SDK（如 TypeScript、Python、Go、Rust）。

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

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 或非主題頻道以培養歸屬感、明確並公開專案使命。

🚀 Git 2.51 更新亮點​

Source: https://github.blog/open-source/git/highlights-from-git-2-51/

• 無碎片的 Multi-Pack Indexes (MIDXs)：
  • Git 2.51 引入新的打包行為，允許將無法到達的物件（“cruft pack” 中的物件）儲存在 MIDX 之外，解決了先前將它們排除在 MIDX 之外的困難。
  • 透過 repack.MIDXMustContainCruft 配置選項，可使非碎片套件集在可達性上是封閉的。
  • 這項改進在 GitHub 內部應用中，顯著縮小了 MIDXs 檔案大小（約 38%），寫入速度提升（35%），整體儲存庫讀取性能提高（約 5%）。
• Path Walk 實現更小尺寸的 Packfiles：
  • Git 2.49 引入了 "name-hash v2" 以改進物件的 Delta 壓縮。
  • Git 2.51 更進一步，引入了新的「path walk」物件收集方式，在打包時一次性處理來自相同路徑的所有物件。
  • 這種方法避免了名稱哈希啟發式，並可在已知位於相同路徑的物件組內尋找 Delta，從而產生通常更小尺寸的 Packfiles。可透過 --path-walk 命令列選項試用。
• Stash 交換格式：
  • 過去 Git Stash 內部透過創建三個提交來儲存狀態，且 refs/stash 只儲存一個 Stash 項目，導致跨機器遷移困難。
  • Git 2.51 引入了新的 Stash 內部表示形式，允許將多個 Stash 項目表示為一系列提交，類似於普通的提交日誌，新的 Stash 提交包含四個父級。
  • 新版本新增了 git stash export --to-ref 和 git stash import 子命令，使得 Stash 內容可以像普通分支或標籤一樣進行匯出、推送和拉取，實現跨機器遷移。

  # 在一台機器上
  git stash export --to-ref refs/stashes/my-stash
  git push origin refs/stashes/my-stash
  
  # 在另一台機器上
  git fetch origin '+refs/stashes/*:refs/stashes/*'
  git stash import refs/stashes/my-stash
  

• git cat-file 改進：
  • git cat-file 是用於列印物件原始內容的專用工具。
  • 在 Git 2.51 之前，查詢子模組路徑會顯示 missing。
  • Git 2.51 改善了此輸出，使其在指令碼場景中更有用，現在能正確識別子模組物件 ID 和類型。

  # [ pre-2.51 git ]
  echo HEAD:sha1collisiondetection | git cat-file --batch-check
  # HEAD:sha1collisiondetection missing
  
  # [ git 2.51 ]
  echo HEAD:sha1collisiondetection | git cat-file --batch-check
  # 855827c583bc30645ba427885caa40c5b81764d2 submodule
  

• Bloom Filter 改進：
  • Git 2.51 增加了對使用多個路徑規範項目的支持，例如 git log -- path/to/a path/to/b，這些以前無法利用已更改路徑的 Bloom filter。
• git switch 和 git restore 不再是實驗性命令：
  • 這兩個命令自 Git 2.23 引入以來，已穩定運行六年，其命令列介面已穩定並向後相容。
• git whatchanged 命令被棄用：
  • 此命令已被標記為棄用，並計畫在 Git 3.0 中移除，但仍可透過 --i-still-use-this 旗標使用。
• Git 3.0 的重大變更預告：
  • reftable 後端將成為 Git 3.0 中新建立儲存庫的預設格式。
  • SHA-256 哈希函數將成為 Git 3.0 中初始化新儲存庫的預設哈希函數。
• Git 內部開發流程更新：
  • 允許在程式碼庫中使用 C99 bool 關鍵字。
  • 修訂了貢獻補丁的準則，允許貢獻者使用其合法姓名以外的身份提交補丁，與 Linux 核心的方法更接近。

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

🚨 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 的合作不僅提升了其開源專業知識，也為其開源未來奠定了堅實基礎。

🔗 大規模保障供應鏈安全：從 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）等多個關鍵領域。
• 該計劃的成功關鍵在於：資金支援結合時間限制的專注訓練、互動式編碼經驗以及建立一個以安全為重點的社群，促進了維護者之間的快速交流與協作。

加速 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 合規性的安全證據。

使用 GitHub Models 在 Actions 中自動化您的專案 🚀​

Source: https://github.blog/ai-and-ml/generative-ai/automate-your-project-with-github-models-in-actions/

• GitHub Models 將 AI 整合到 GitHub Actions 工作流程中，實現專案內的自動化分類、摘要等功能。
• 權限設置： 使用 GitHub Models 前需在 permissions 區塊中加入 models: read，並建議遵循最小權限原則，以降低提示詞注入攻擊 (prompt injection) 風險。

  permissions:
    contents: read
    issues: write
    models: read
  

• 範例一：在 Bug 報告中請求更多資訊
  • 透過 actions/ai-inference@v1 動作分析 Issue 內容，判斷錯誤報告是否包含足夠的重現資訊（例如：重現步驟、預期行為、實際行為、環境細節）。
  • 若資訊不足，AI 會自動回覆提示作者補齊。此機制利用 AI 模型的回傳值（pass 或詳細說明）建立工作流程中的條件邏輯。

  - name: Analyze Issue For Reproduction
    if: contains(join(github.event.issue.labels.*.name, ','), 'bug')
    id: analyze-issue
    uses: actions/ai-inference@v1
    with:
      model: mistral-ai/ministral-3b
      system-prompt: |
        Given a bug report title and text for an application, return 'pass' if there is enough information to reliably reproduce the issue, meaning the report clearly describes the steps to reproduce the problem, specifies the expected and actual behavior, and includes environment details such as browser and operating system; if any of these elements are missing or unclear, return a brief description of what is missing in a friendly response to the author instead of 'pass'. Consider the following title and body:
      prompt: |
        Title: ${{ steps.issue.outputs.title }}
        Body: ${{ steps.issue.outputs.body }}
  

• 範例二：從合併的 Pull Request 建立發布說明
  • 透過 gh CLI 搭配 gh-models 擴充功能，在 Pull Request 合併時自動摘要其標題、內容、評論及審閱，並將摘要內容追加到指定的發布說明 Issue 中。

  cat pr.json | gh models run xai/grok-3-mini \
    "Given the following pull request information, generate a single, clear, and concise one-line changelog entry that summarizes the main change (feature, fix, or bug) introduced by this PR. Use neutral, user-facing language and avoid technical jargon or internal references. Only write the line, with no additional introduction or explanation text." > summary.md
  

• 範例三：摘要並優先處理 Issue
  • 設定定期排程工作流程 (例如每週一早上 9 點)，使用 gh CLI 抓取過去一週新開啟的 Issue，並將其傳遞給 AI 模型進行摘要、歸納主題及優先級排序，最終創建一個新的 Issue 來呈現週報摘要。
  • 此範例使用獨立的 .prompt.yml 提示文件，提供更複雜的提示邏輯。

Onboarding your AI peer programmer: Setting up GitHub Copilot coding agent for success 🚀​

Source: https://github.blog/ai-and-ml/github-copilot/onboarding-your-ai-peer-programmer-setting-up-github-copilot-coding-agent-for-success/

• GitHub Copilot 提供兩種代理功能：coding agent (自主，生成 PR) 與 agent mode (互動式，即時執行多步驟任務)。
• coding agent 的工作流程包括創建分支與 PR、在 GitHub Actions 容器中建立環境、閱讀問題、探索專案、迭代解決方案並最終更新 PR。
• 可透過自訂 GitHub Actions workflow 檔案（例如 .github/workflows/copilot-setup-steps.yml）來配置 Copilot 的執行環境，確保其能存取所需的工具和服務。

  name: "Copilot Setup Steps"
  
  on:
    workflow_dispatch:
    push:
      paths:
        - .github/workflows/copilot-setup-steps.yml
    pull_request:
      paths:
        - .github/workflows/copilot-setup-steps.yml
  
  jobs:
    copilot-setup-steps:
      runs-on: ubuntu-latest
      permissions:
        contents: read
      steps:
        - name: Checkout code
          uses: actions/checkout@v4
  
        - name: Set up Python
          uses: actions/setup-python@v4
          with:
            python-version: "3.13"
            cache: "pip"
  
        - name: Install Python dependencies
          run: pip install -r requirements.txt
  
        - name: Install SQLite
          run: sudo apt update && sudo apt install sqlite3
  

• 撰寫清晰明確的 Issue 與提示對 Copilot 成功生成高品質 PR 至關重要，應包含問題陳述、重現步驟、相關歷史、建議方法等。
• 透過優化專案結構（README、代碼註釋、良好命名）和自訂指令文件（copilot-instructions.md 或 <file-name>.instructions.md）來提供 Copilot 上下文資訊和組織規範。

  # Classic arcade
  
  This project hosts a classic arcade, themed after the 1980s 8-bit games.
  
  ## Standard player flow
  
  1. Player opens app and sees list of games.
  2. Player selects game to play.
  3. Player sees a splash screen with the message "Insert quarter".
  4. Player presses space to start game and plays game
  6. After game ends, the "Game over" message is displayed.
  7. The player score is checked against high scores. If the score is in top 10, user is prompted for their initials (3 initials).
  8. High scores are displayed, and an option to return to the main menu to start over again.
  
  ## Frameworks
  
  - Python `arcade` library is used for the arcade itself
  - SQLite is used to store all scores
  
  ## Coding guidelines
  
  - All games must inherit from `BaseGame`
  - Python code should follow PEP8 practices, including docstrings and type hints
  
  ## Project structure
  
  - `data`: Stores data abstraction layer and SQLite database
  - `games`: Stores collection of games and `BaseGame`
  - `app`: Stores core app components including menuing system
  

• 可利用 Model Context Protocol (MCP) 擴展 Copilot 的上下文和工具，例如透過 Azure MCP server 支持 Bicep 程式碼生成。

  {
    "mcpServers": {
      "AzureBicep": {
        "type": "local",
        "command": "npx",
        "args": [
          "-y",
          "@azure/mcp@latest",
          "server",
          "start",
          "--namespace",
          "bicepschema",
          "--read-only"
        ]
      }
    }
  }
  

• Copilot coding agent 內建防火牆，可限制對核心服務的存取，以管理數據外洩風險；遠端 MCP server 或網路資源存取需更新允許列表。