D3「設定與使用供應鏈安全」14 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
匯出的 SBOM 包含下列哪項資訊？
單選題，選項：
正確答案：相依性的間接路徑與授權資訊
解析：SBOM 包含相依性、版本、套件識別碼、授權、間接相依性路徑與著作權資訊；不包含依賴你的專案（dependents）。
常見陷阱：SBOM 描述你依賴什麼，不描述誰依賴你。
依據：Exporting a software bill of materials for your repository
Dependency graph 會為私有 repository 列出 dependents（依賴它的其他 repository）。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：Dependents 只在公開 repository 列出，私有 repository 不回報這項資料。
常見陷阱：私有 repository 同樣能使用 dependency graph 檢視自己的 dependencies，但 dependents 只對公開 repository 提供。
用 REST API 請求產生 SBOM 後，回應為 202 時應該怎麼做？
單選題，選項：
正確答案：輪詢 sbom_url 直到回應為 302
解析：請求產生後要輪詢 sbom_url；回應為 202 表示尚未完成，回應為 302 時依重新導向下載完成的 SBOM。
常見陷阱：202 代表已受理、尚未完成，不是結果。
依據：Exporting a software bill of materials for your repository
官方文件建議在排定 Dependabot 警示優先順序時，一併參考哪些項目？（選 4 項）
複選題，選項：
正確答案：弱點的嚴重度等級；EPSS 利用預測分數；相依性的範圍（scope）；相依性的直接或間接關係
解析：文件建議合併參考嚴重度、EPSS 分數、相依性的範圍與相依性的關係；另可選用 reachability analysis。
常見陷阱：授權類型屬於 dependency review 與授權合規的判斷項目，不是警示優先順序的依據。
團隊只想讓 Dependabot 為部分警示開 pull request，官方建議的做法是什麼？
單選題，選項：
正確答案：停用 security updates 並建立 auto-triage 規則
解析：啟用 security updates 後會為每個有可用修補的開啟警示開 pull request；要自行挑選，官方建議停用它並建立 auto-triage 規則。dependabot.yml 與警示之間沒有互動。
常見陷阱：dependabot.yml 的設定看似能篩選，但它與 Dependabot 警示沒有互動。
Dismiss package malware alerts 這條 GitHub 預設規則，在公開 repository 預設啟用。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：Dismiss package malware alerts 預設停用，但可為任何使用 Dependabot malware alerts 的 repository 啟用；預設啟用的是 Dismiss low impact issues for development-scoped dependencies（公開 repository）。
常見陷阱：兩條預設規則容易互換；惡意套件警示被自動關閉有風險，所以預設停用。
首次啟用 Dependabot alerts 時，對 repository 中已存在的弱點，GitHub 會如何通知？
單選題，選項：
正確答案：不通知既有弱點，只通知啟用後新發現的
解析：首次啟用時，GitHub 不會為已找到的弱點寄通知，只會通知啟用後新發現的相依性弱點（視通知偏好而定）。
常見陷阱：啟用當下的大量既有警示不會引發通知，但警示仍然存在於清單中。
某警示被 auto-triage 規則自動關閉，之後相依性的範圍從 development 改成 production。這則警示會如何？
單選題，選項：
正確答案：可能被自動重新開啟
解析：自動關閉的警示在中繼資料改變時可以被自動重新開啟，例如相依性範圍從 development 改成 production，或 GitHub 修改 advisory 的某些中繼資料。
常見陷阱：自動關閉不是永久：它仍可查詢、可手動重新開啟，也可能因中繼資料改變而自動重開。
依據：Dependabot auto-triage rules、Managing alerts that have been automatically dismissed by a Dependabot auto-triage rule
Dependency review action 預設只有在發現 critical 嚴重度的弱點時，檢查才會失敗。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：預設情況下，只要發現有弱點的套件，檢查就會失敗；fail-on-severity 是用來設定達到哪個嚴重度才失敗的選用設定。
常見陷阱：嚴重度門檻要自己設定，預設並不是只看 critical。
下列哪些是 dependency review action 官方範例中可設定的選項？（選 3 項）
複選題，選項：
正確答案：fail-on-severity；fail-on-scopes；allow-ghsas
解析：範例中的選項包含 fail-on-severity、allow-licenses 或 deny-licenses（只能擇一）、allow-ghsas 與 fail-on-scopes。
常見陷阱：選項名稱相近，只有範例中出現的才算；allow-licenses 與 deny-licenses 不能同時使用。
組織要讓所有 repository 的 pull request 必須通過 dependency review 才能合併，應該設定什麼？
單選題，選項：
正確答案：branch ruleset 要求 workflow 通過才合併
解析：先在某個 repository 設定好 dependency review action，再建立 branch ruleset，啟用 Require workflows to pass before merging，並指定該 workflow。
常見陷阱：Dependabot 設定管理警示與更新，不是合併前的強制檢查。
Dependabot version updates 預設的 cooldown 是多久？
單選題，選項：
正確答案：3 天
解析：預設有 3 天的 cooldown，新版本發布後 3 天才會被考慮；此預設不適用於 security updates，可用 cooldown 選項自訂。
常見陷阱：預設 cooldown 只適用於 version updates，security updates 不受它延遲。
GitHub Team 組織沒有 Code Security 或 Advanced Security 授權，能否指派公開 repository 的 Dependabot 警示？
單選題，選項：
正確答案：不可以，指派需要授權，公開也一樣
解析：指派 Dependabot 警示需要 Code Security 或 Advanced Security 授權，官方明說包含公開 repository。
常見陷阱：公開 repository 的許多功能免費，但警示指派不在其中。
Dependabot 警示的指派者變更時，GitHub 會送出哪個 webhook 事件？
單選題，選項：
正確答案：assignees_changed
解析：指派者變更時 GitHub 送出 assignees_changed webhook 事件，可用來觸發 workflow 或與外部系統同步。
常見陷阱：事件名稱要記原文；其餘三個是看似合理的虛構名稱。