三狀態模型

Closed（正常）

所有呼叫正常通過。熔斷器記錄成功和失敗的計數。

Open（熔斷）

當失敗率或連續失敗次數超過閾值時，熔斷器進入 open 狀態。此後所有呼叫立即回傳錯誤，不實際呼叫外部依賴。

Open 狀態持續固定時間（如 30 秒），時間到後進入 half-open。

Half-open（探測）

允許少量呼叫（如 1 個）實際通過到外部依賴。如果成功 → 回到 closed；如果失敗 → 回到 open（重設計時器）。

Half-open 的目的是自動探測依賴是否恢復，不需要人工介入。

熔斷判斷條件

「失敗」的定義需要明確：HTTP 5xx 是失敗、4xx 通常不是（client 的問題）、timeout 是失敗、connection refused 是失敗。

熔斷時的 fallback

熔斷觸發後，呼叫端收到的是「快速失敗」而非逾時。呼叫端需要有 fallback 策略：

沒有 fallback 的依賴被熔斷 = 對應功能完全不可用。熔斷器保護的是「不讓不可用的功能拖垮整個服務」。

監控系統的應用

Collector 的 rule engine 在規則命中時可能呼叫外部服務（Slack webhook、HTTP POST 到 alert endpoint）。如果外部服務掛了，每個命中的規則都會等待逾時 — 大量規則命中時 goroutine 積壓。

熔斷器包在 rule engine 的「執行外部動作」環節：連續 5 次外部呼叫失敗 → 熔斷 → 後續規則命中不再嘗試外部呼叫、改寫本地 log → 30 秒後探測一次 → 外部服務恢復 → 恢復正常呼叫。

下一步路由

• 被動的流量控制 → 背壓機制
• 主動的速率限制 → Rate Limiting
• 不同工作負載的資源隔離 → Bulkhead 隔離

本篇同時處理服務之間依賴的表達方式 — output 與 data source — 因為依賴表達直接影響 stateful 資源的爆炸半徑：同一份 state 裡的資料庫跟運算綁在一起 apply，還是拆成獨立 state 各自演進，決定了一次 apply 失敗會波及多少資源。

stateful 資源的保護策略

stateful 資源的 IaC 描述要把「保護狀態」當成第一類需求，而非事後補上的選項。保護的三個面向 — 可用性、可還原性、防誤刪 — 各自對應不同的機制，混在一起談會讓判斷失焦。

multi-AZ 的職責邊界

multi-AZ 用一個布林屬性開啟，背後是 RDS 在另一個可用區維護同步副本。它承擔的是可用性：主庫所在的可用區故障時，RDS 自動 failover 到 standby，服務在秒級到一兩分鐘的窗口後恢復。

multi-AZ 的邊界要明確界定，因為把它當成超出職責的工具會在事故裡踩空：

• standby 是熱備不可讀。multi-AZ 的 standby 不接受任何查詢流量，所以它不提供讀取擴展。要分攤讀流量得另開 read replica，這是另一個資源、另一個端點、另一套複寫延遲要管。
• failover 有切換窗口。切換期間應用的資料庫連線會中斷、需要重連。應用層如果沒有處理連線中斷的重試邏輯，failover 就會變成一段可見的服務中斷，而非透明切換。
• 它不防邏輯損壞。誤刪一張 table、一筆錯誤的批次 UPDATE、一段有 bug 的 migration script — 這些操作會同步複製到 standby。multi-AZ 防的是硬體與可用區故障，邏輯損壞的防線是備份與時間點還原（PITR）。

這三條邊界說明 multi-AZ 和 backup 的職責正交：前者解可用性，後者解可還原性。兩者要分別配置、分別驗證。成本參考：multi-AZ RDS 的費用約為 single-AZ 的兩倍（standby instance 按相同規格計費）。這筆費用對應的能力是可用區故障時的分鐘級自動 failover——判斷值不值得時，用主庫所承載的服務停機每小時的商業代價來衡量。

備份保留與時間點還原

backup 用保留天數與備份視窗描述。RDS 依此每日自動快照並保留交易日誌，以支援還原到任意時間點（PITR）。自動備份的保留上限是 35 天，更長的留存要靠手動快照或匯出到 S3 自行管理。

backup_retention_period 取多少天，以 RPO（Recovery Point Objective）與合規要求反推。RPO 問的是「出事時最多能接受遺失多久的資料」— PITR 能還原到最近 5 分鐘內的時間點，但前提是自動備份有開、交易日誌有保留。保留天數決定的是「能回溯多遠」：14 天是 AWS RDS 自動備份 35 天上限的保守折衷，足以涵蓋多數營運場景下「發現問題到決定還原」的時間差；受監理的服務往 30 天推，以滿足稽核追溯窗口。

1resource "aws_db_instance" "primary" {
2  multi_az                  = true
3  backup_retention_period   = 14
4  backup_window             = "03:00-04:00"
5  deletion_protection       = true
6  skip_final_snapshot       = false
7  final_snapshot_identifier = "app-prod-final-${formatdate("YYYYMMDD", timestamp())}"
8}

備份視窗選在流量低谷（如 UTC 凌晨），避免快照 IO 跟尖峰流量競爭。手動快照用獨立資源描述，常見用途是重大變更前的保險點 — 大版本升級、schema migration、或任何會改變資料結構的操作。

刪除保護與 final snapshot

deletion_protection = true 讓 terraform destroy 無法直接刪除這個 instance — 要先用另一次 apply 把保護關掉，這一步本身就會出現在 plan 裡、被 review 攔住。skip_final_snapshot = false 確保即使確實要刪，也會先拍一份最終快照。兩者搭配是正式資料庫的硬性下限。

該在 review 攔下的訊號是：正式環境的 stateful 資源若 backup_retention_period 為 0 或 deletion_protection 為 false，代表狀態保護沒有寫進程式碼。把這些屬性視為正式資料庫的預設值，而非可調的偏好。

S3 bucket 的保護同理但機制不同。versioning 讓覆寫或刪除的物件可以回到先前版本；MFA delete 要求刪除前提供第二因素驗證；lifecycle rule 控制舊版本的保留時間 — 這三者分別對應「可還原」「防誤刪」「控成本」三個職責，見儲存（S3）。

跨 region 災難復原的邊界

multi-AZ 解的是可用區級故障 — 單一資料中心出問題時，同 region 的另一個可用區接手。跨 region 的災難復原（cross-region read replica、S3 cross-region replication、Route 53 failover routing）屬於更高級的可用性投資，解的是整個 region 不可用的極端情境。它的成本與複雜度顯著上升：跨 region 複寫有延遲、failover routing 需要健康檢查與 DNS TTL 配合、兩個 region 的 infra 要各自維護。多數服務在單 region 的 multi-AZ + 備份做完之後再評估是否需要跨 region，依據是業務的 RTO（Recovery Time Objective）對 region 級故障的容忍度。

跨 region 的 infra 投資在 B2B SaaS 的合約義務下更容易成立。Genesys 的客服平台跨 15 個 region 用 DynamoDB 達成 99.999% 可用性——年停機只有 5 分鐘。對 B2B SaaS 來說，客戶服務中斷等於客戶的終端使用者打不通電話，可用性是合約義務而非行銷敘述。infra 層的判斷依據是：multi-AZ 不夠用（業務需要跨 region failover）的情況通常由合約 SLA 驅動，而非技術判斷驅動。

stateful 與 stateless 的操作差異

stateful 與 stateless 資源的根本差別在重建代價。這個差別傳導到三個操作後果，每一個都影響日常的 PR review 與 apply 流程。

刪除保護的必要性

stateless 資源（ECS service、ALB、無狀態運算）重建只是換一組新實例，幾分鐘內恢復、沒有資料損失，所以它們可以被頻繁地 destroy 與 recreate — 這是 IaC 最擅長的對象。stateful 資源重建意味著資料遺失或漫長的還原，代價可能是數小時的停機與不可逆的損失。開啟 deletion protection 讓「不小心 destroy」需要先顯式關閉保護這一步，多一道人為確認。

drift 容忍度

stateless 資源的 drift 可以靠重建抹平 — apply 一次就回到程式碼的狀態，副作用只是新實例的短暫滾動更新。stateful 資源的 drift 要謹慎處理，因為 IaC 的「修正回程式碼狀態」動作可能觸發重啟甚至重建。

一個常見的情境：某人手動改了 RDS 的 parameter group，Terraform plan 顯示要把它改回程式碼的版本。這個改回動作是 update in-place（改設定、不重建）還是 replace（先刪後建），取決於哪個參數被改了 — 某些 parameter 的修改需要重啟，而某些需要整個 instance 重建。判讀方式是先跑 plan、看 drift 修正的結果，update in-place 通常安全（可能觸發重啟），replace 對資料庫意味著先刪後建，在 prod 上需要額外的確認。

變更審查強度

改動 stateful 資源的 plan 輸出要逐行看，特別警惕任何顯示為 replace（-/+）或標記 forces replacement 的項目。某些欄位的改動看似無害但會觸發 replace：

Review 時看到 stateful 資源出現 forces replacement，在 prod 路徑上幾乎都該先暫停、確認回退路徑（手動快照是否已拍）再決定是否繼續。常見做法是把這個差別寫進流程：stateful 資源的變更走更嚴格的 PR review 與分階段套用（先在 dev apply 驗證、確認是 in-place 後再推 prod），自動化護欄在模組七：infra 走 PR 流程展開。

服務之間的依賴怎麼表達

服務間依賴用 output 與 data source 表達，讓引用關係成為程式碼裡可追蹤的邊，而非靠人記憶的隱性約定。引用方式的選擇直接影響 state 的大小與爆炸半徑。

同 state 內的引用

同一個 state 內，直接引用資源屬性即可建立依賴。運算資源引用資料庫的端點，IaC 自動推導出「資料庫先於運算」的邊，也讓端點變更時上層自動取得新值：

1resource "aws_ecs_task_definition" "api" {
2  container_definitions = jsonencode([{
3    environment = [
4      { name = "DB_HOST", value = aws_db_instance.primary.endpoint }
5    ]
6  }])
7}

同 state 引用的好處是依賴圖最完整 — apply 一次就把所有引用解析到正確的值。代價是 state 越大、單次 apply 的爆炸半徑越大。一份包含網路、資料庫、運算、LB 的 state，一次 apply 失敗可能讓所有資源處於半完成狀態。

跨 state 的 data source

跨 state（例如網路地基與核心服務分屬不同 Terraform state，呼應模組四：環境分離與模組化的拆分）時，下游用 data source 唯讀地讀取上游已建立的資源：

 1data "aws_vpc" "main" {
 2  tags = { Name = "app-${var.env}" }
 3}
 4
 5data "aws_subnets" "private" {
 6  filter {
 7    name   = "vpc-id"
 8    values = [data.aws_vpc.main.id]
 9  }
10  tags = { tier = "private" }
11}

下游查詢上游的 VPC 與 subnet，取得 ID 來放置自己的資源，而不複製貼上硬編碼的值。

同 state vs 跨 state 的取捨

兩種方式的取捨在耦合與隔離之間：

用 grep 搜一遍核心服務的 HCL：如果出現大量寫死的 subnet ID 或 VPC ID，代表該用 data source 而沒用。這些硬編碼是日後上游重建時 drift 與 broken reference 的來源。把它們換成 data source，依賴關係才會在程式碼裡顯性化、可被工具與 review 看見。

data source 查詢的可靠性取決於查詢條件的穩定度。用 tags 查比用 Name 查更穩 — tag 是自己定義的、可控的值，而某些資源的 Name 可能在重建時改變。用 terraform_remote_state data source 直接讀上游的 state output 是最精確的方式，但它把兩份 state 的 backend 設定耦合在一起，上游搬 state 時下游也要跟著改。在團隊規模小、state 拆分不多的階段，terraform_remote_state 的耦合代價通常可接受；團隊變大後，用 tag-based data source 或 SSM Parameter Store 當中間層，能讓上下游各自獨立演進。

跨分類引用

• → 模組三：網路地基：核心服務落在哪些 subnet、security group 怎麼引用
• → 模組四：環境分離與模組化：跨 state 的拆分策略
• → 模組七：infra 走 PR 流程：stateful 變更的自動化護欄

服務定位

Dependabot 的核心定位是 把依賴升級從人工 ritual 變成 PR review 工作流。它把「找新版」「跑 manifest update」「開 PR」「附 release note」自動化、剩下的 是否合併 留給人類 / CI 判斷。這跟 Snyk 看似重疊 — 兩者都會自動發升級 PR — 但 Snyk 是 跨 SCM + 多 stack（GitHub / GitLab / Bitbucket、SCA + 容器 + IaC + Code）、Dependabot 是 GitHub-only + 純依賴。多數組織選一個、混用兩者會在同一個 manifest 上各自開 PR、造成 noise。

跟 GHAS 的關係比較細：Dependabot Alerts 跟 Security Updates 本身是 GHAS Dependabot 子模組的核心、但功能上 Alerts 對所有 repo 免費、Security Update 也免費自動發 PR、Version Update 也免費；GHAS 提供的是 Dependency Review（PR-time gate、阻擋 PR 引入新漏洞依賴）、Security Overview（org-wide dashboard）跟 enterprise-level 控制。Dependabot 是 background PR 工廠、GHAS Dependency Review 是 PR-time blocker、兩者互補不重疊。

跟 Renovate（Mend 維護的 OSS）的差異：Renovate 配置更彈性、跨 SCM、支援 ecosystem 數量多（含 Helm chart、Docker tag、ArgoCD 等）、Grouped Updates 規則更細；Dependabot 整合 GitHub 原生 UI（Security tab、Dependency graph、PR diff）更深、設定簡單。需要 跨 SCM 或 Helm / ArgoCD / 自訂 ecosystem 走 Renovate；單純 GitHub-only 加 npm / Maven / pip 等主流 ecosystem、Dependabot 配置成本更低。

本章目標

讀完本頁、讀者能判斷：

1. Dependabot 在 supply chain 防護裡承擔哪一段（背景 PR 升級）、哪些不在它責任內（容器掃描、IaC 掃描、PR-time gate）
2. dependabot.yml 的關鍵配置面：ecosystem、schedule、open-pull-requests-limit、groups、reviewers
3. Version Update vs Security Update vs Alerts 三個功能何時開、PR noise 怎麼控制
4. Auto-merge 政策的邊界：哪種更新可以全自動、哪種要保留 human approval

最短判讀路徑

判斷一個 repo 的 Dependabot 配置是否健康、最少看四件事：

• dependabot.yml 配置：repo 是否有 .github/dependabot.yml、ecosystem 是否覆蓋所有 manifest（npm / Maven / pip / Docker / GitHub Actions / Terraform）、directory 路徑對不對（monorepo 各 sub-package 是否獨立配置）
• Update Schedule：schedule.interval 是 daily / weekly / monthly、open-pull-requests-limit 是否合理（預設 5、太低會卡住 backlog、太高會 PR noise）、Grouped Updates 是否啟用（減少 minor / patch PR 數量）
• Auto-merge 政策：branch protection 是否設「CI green + required reviewer」、auto-merge 是否限定 patch + minor 自動、major 強制 human review、production 跟 staging branch 是否有差異化規則
• Token 治理：repo secrets 是否被 Dependabot PR 誤用、Dependabot secrets（私有 registry credential）是否獨立配置、PR 觸發的 Actions 是否假設 read-only token

四件事任一缺失、就是 Supply Chain Integrity 邊界的待補項目。

日常操作與決策形狀

dependabot.yml 是版控的配置檔：放在 .github/dependabot.yml、跟 manifest 同 repo、所有變更走 PR review。不在 GitHub UI 直接改 — UI 只能 啟用 / 停用 Dependabot 本身、細節必須 commit 進 repo。Monorepo 結構（例：/services/api、/services/web 各自 package.json）每個 sub-package 寫一個 entry、directory 指到 sub-package 根目錄、package-ecosystem 標 manifest 類型。schedule.interval 一般 weekly 開始、daily 適合高活躍度團隊但 PR noise 高、monthly 適合穩定 lib 但 CVE 延遲風險高。

Version Update vs Security Update 分開：Version Update 是 定期掃 manifest 看有沒有 newer compatible 版本、不分 CVE、是 hygiene 工作；Security Update 是 Dependabot 偵測到 CVE 且 manifest 指到 vulnerable 範圍時自動發 PR 升級到 fix version、是 incident 工作。多數組織開 Security Update 全 repo + 選擇性開 Version Update（核心服務開、archived repo 不開）— 避免 PR noise 淹沒緊急 PR。Security Update 預設啟用、Version Update 要 explicit 在 dependabot.yml 寫 entry 才會跑。

Grouped Updates：2023 推出、單一 PR 含多個 minor / patch 升級（例：一個 PR 升 10 個 npm package）、PR 數量從 10 個降到 1 個。配置在 dependabot.yml 的 groups 區、可以按 dependency name pattern（例：@types/* 一組、eslint* 一組）或 update-type（patch / minor 分組）。Major version 仍分開 PR — 因 breaking change 風險、需要單獨 review。Grouped Updates 配 auto-merge 是 minor / patch 全自動 的標準配置。

Auto-merge 是 PR 級、不是 commit 級：Dependabot 發 PR、搭配 GitHub branch protection 設「CI green + 1 approver」就 auto-merge — GitHub gh pr merge --auto 或 Actions workflow（peter-evans/enable-pull-request-automerge）都行。production 環境應該保留 human approval（至少對 major version）、staging / dev 可以全自動。常見模式：staging branch 全自動合（patch + minor）+ 自動 deploy；production branch 走 staging → cherry-pick / promote 流程、human approve。

Reviewer / Assignee / Label 自動標記：dependabot.yml 的 reviewers / assignees / labels 欄位讓 Dependabot 開 PR 時自動標 reviewer 跟 label。實務上配 labels: ["dependencies"] 讓 Dependabot PR 在 PR list 跟一般 feature PR 分開、CI workflow 可以針對 dependencies label 跑特化 lint（例：跑完整 e2e、不只 unit test）。

Token 治理：Dependabot PR 跑 GitHub Actions 時、secrets.GITHUB_TOKEN 是 read-only（GitHub 設計上限制、防 PR 觸發 supply chain attack）— 這代表 Dependabot PR 不能跑需要 write permission 的 job（推 image / 改 status / comment）。需要的話用 pull_request_target event（用 base branch 的 workflow + 完整 secrets）、但這也是 supply chain attack 高風險面、必須 最少 permission。私有 registry credential（npm private registry token、Maven private repo password）用 Dependabot secrets（org / repo level）配置、跟 GitHub Actions secrets 是 不同 namespace、不會互相讀到。

跟 GHAS Dependency Review 搭配：GHAS Dependency Review 在 PR-time 看 manifest diff 阻擋 引入新漏洞依賴、Dependabot Security Update 在 background 升級舊有漏洞依賴、兩個方向互補。production repo 標準配置：GHAS Dependency Review 設 high severity block + Dependabot Security Update 全開 + Dependabot Version Update 選擇性開。

核心取捨表

選 Dependabot 的核心訴求：GitHub-only + 只要依賴 PR 自動化、不要容器 / IaC scan、配置成本要低、整合 GitHub Security tab。要跨 SCM 或多 stack 走 Snyk、要彈性 ecosystem / Helm chart / ArgoCD 走 Renovate。混用 Dependabot + Snyk 對同一 manifest 自動 PR 會 noise、二選一。

進階主題

Multi-ecosystem repo：一個 repo 同時有 npm + Docker + Terraform + GitHub Actions、dependabot.yml 寫四個 entry、各自 schedule。實務常見配置：application 依賴（npm / pip）weekly、base image（Docker）weekly、IaC（Terraform provider）monthly、GitHub Actions（CI workflow）weekly。Actions ecosystem 要特別注意 — Dependabot 升級 uses: 指向的 action version、可以同時 pin commit hash（防 tag re-publish 攻擊）、但 pin hash 後 release note 看不到 — 取捨 安全 vs 可讀性。

Private registry support：私有 npm registry（GitHub Packages / Artifactory / Nexus）、私有 Maven repo、私有 PyPI mirror、私有 container registry 都要在 dependabot.yml 配置 registries 區、credential 走 Dependabot secrets。Dependabot 從私有 registry 抓 package metadata 跟 release info、否則只能看 public registry、會誤判 internal lib 沒新版。Org-level Dependabot secrets 適合共用 credential、repo-level 適合特殊 credential 隔離。

Self-hosted runner 隔離：Dependabot PR 觸發的 Actions 預設跑在 GitHub-hosted runner、跟 Dependabot 本身的 sandbox 不同。如果 CI 跑在 self-hosted runner（內網資源 / 大 build cache）、Dependabot PR 也會跑在 self-hosted runner — 要確認 runner 不會被 PR 注入的惡意 manifest 攻擊（npm install 跑 postinstall script 是經典攻擊路徑）。Mitigation：Dependabot PR 用 ephemeral runner（每次新 VM）、隔離 build cache、不掛 sensitive volume。

Auto-merge 風險：auto-merge 加速合併、但也放寬 攻擊者升級 dep 攻擊我 的窗口。XZ Backdoor 2024 的攻擊路徑就是攻擊者花兩年取得 upstream maintainer 信任、發 release 帶 backdoor — 如果下游 auto-merge 升級、攻擊就直達 production。Mitigation：major version 永不 auto-merge、critical infra dep（auth / crypto / network 函式庫）pin commit hash + 手動 review、auto-merge 範圍縮到 patch + minor + low-criticality dep。

GitHub Actions 跟 Dependabot 互動：Dependabot PR 觸發的 workflow 預設 GITHUB_TOKEN 是 read-only、secrets.* 是 empty（Dependabot context）— 防止 PR 注入腳本竊取 secret。需要在 Dependabot PR 跑帶 secret 的 job、用 pull_request_target event（workflow 從 base branch 取、有完整 secret）— 但這會 讀 PR 的 code 跑 workflow、必須先 checkout base 然後最小化 PR code 的執行（不跑 PR 的 install script、只跑既有 lint）。

排錯與失敗快速判讀

• PR noise 淹沒緊急 PR：Version Update 全開 + 沒 Grouped Updates、一週 30+ PR — 啟用 groups 按 pattern 分組（@types/* / eslint* / dev-dependencies）、open-pull-requests-limit 設 5、archived repo 關 Version Update
• Security Update 沒發 PR：CVE 公告了但 Dependabot 沒動 — 確認 manifest 真的指到 vulnerable 範圍、dependabot.yml 沒 ignore 該 dependency、Security Updates 在 repo settings 是啟用、Dependency graph 有抓到該 manifest
• 私有 registry 抓不到：Dependabot 在私有 npm / Maven repo 失敗 — dependabot.yml 配 registries 區、credential 進 Dependabot secrets（不是 Actions secrets）、URL 跟 token 範圍對齊
• Auto-merge 不觸發：PR 開了 CI 也綠了但沒合 — 確認 branch protection required check 跟 CI workflow 名稱對齊、gh pr merge --auto 在 PR comment / workflow 有觸發、reviewer count 達標
• Dependabot PR 跑 Actions 失敗：PR 的 workflow 報 permission denied — GITHUB_TOKEN 在 Dependabot context read-only、改用 pull_request_target 或拆 job（push secret 的部分跑在 merge 後 main branch event）
• Major version 被 auto-merge：規則沒寫對、major 也自動合進 production — dependabot.yml 的 ignore 加 update-types: ["version-update:semver-major"] 或 auto-merge 條件改 ${{ steps.metadata.outputs.update-type == 'version-update:semver-minor' }}
• Monorepo 漏掃：/services/api/package.json 沒掃 — dependabot.yml 每個 sub-package 寫一個 entry、directory 指到正確路徑、不是只在 root 一個 entry
• GitHub Actions ecosystem 升級拿掉 commit hash pin：原本 uses: actions/checkout@a12b3c4 被升成 uses: actions/checkout@v5 — Dependabot 會 follow 既有 reference 風格、想要 hash pin 設 dependabot.yml 的 ecosystem-level config 但目前限制較多、實務常另用 pinact 或 Renovate 處理 Actions hash pinning

何時改走其他服務

不在本頁內的主題

• dependabot.yml 完整欄位 reference（看 GitHub 官方文件）
• GitHub Advisory Database 詳細運作（CVE 來源、curation 流程）
• GHAS 其他模組（Code Scanning / Secret Scanning / Dependency Review）細節 — 看 GHAS 頁
• Renovate / Snyk 完整配置 — 看各自 vendor 頁
• Container base image 升級的 multi-stage Dockerfile 處理

案例回寫

Dependabot 沒有自身 vendor-level case、但在 supply chain case 中是 標準 mitigation 或 風險面：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact 信任
• 平行：GitHub Advanced Security、Snyk
• 下游：Trivy（容器 scan）、Syft / Grype（SBOM）
• 跨類：artifact 簽章（Sigstore cosign）見 Syft / Grype 頁的 SBOM attestation 段
• 跨模組：6 可靠性驗證流程（Dependabot PR 進 release flow 的 gate 設計）、8 事故處理 vendor 清單
• 官方：Dependabot Documentation