D1「GitHub 安全套件、功能與生態系」14 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
下列哪一項功能在所有 GitHub 方案都能使用，不需要購買 Secret Protection 或 Code Security？
單選題，選項：
正確答案：Dependabot alerts 與 security updates
解析：Dependabot alerts 與 security updates 屬於所有方案都能使用的功能。Security campaigns 需要 Code Security，custom patterns 與 delegated bypass 則需要 Secret Protection。
常見陷阱：其他選項聽起來都像「基本的警示功能」；判斷時要回到功能表，看它列在哪一層，而不是看名稱像不像基礎功能。
Security overview 的各檢視顯示的是組織內所有分支的資料，而不只是預設分支。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：官方說明所有檢視顯示的都是各 repository 預設分支的資訊與指標。
常見陷阱：把 security overview 當成全分支的彙總，會高估或低估實際風險；其他分支上的警示不在這些指標內。
管理員在 security overview 看到某個 repository 沒有任何警示，準備回報「這個 repository 沒有弱點」。想確認這個結論是否可靠，下一步最合適的做法是什麼？
單選題，選項：
正確答案：用 Coverage 檢視確認這個 repository 是否已啟用安全功能
解析：Security overview 顯示的是各功能產生的有效警示。沒有警示，可能是真的沒有問題，也可能是弱點尚未被偵測，或該功能在這個 repository 根本沒啟用；Coverage 檢視用來評估各 repository 採用安全功能的情況。
常見陷阱：四個都是真實的檢視，但只有 Coverage 回答「這個 repository 有沒有啟用偵測」；「沒有警示」本身不能證明沒有風險。
下列哪些屬於 Secret Protection 提供的功能？（選 2 項）
複選題，選項：
正確答案：Custom patterns，自訂 secret 偵測樣式；AI 偵測的 secret，找出無固定格式的密碼
解析：Custom patterns 與 AI 偵測的 secret 屬於 Secret Protection。Dependency review 與 CodeQL CLI 屬於 Code Security。
常見陷阱：兩個套件都包含「掃描」類功能，名稱容易混淆；Secret Protection 管憑證，Code Security 管程式碼與相依性。
團隊想在合併 pull request 之前，了解其中相依性變更的安全影響。應該使用哪個功能？
單選題，選項：
正確答案：Dependency review，檢視新增與更新的相依性
解析：Dependency review 在 pull request 中顯示新增、移除或更新了哪些相依性，以及這些變更的安全影響，讓審查者在合併前判斷是否接受。
常見陷阱：Dependabot 也和相依性有關，但它在合併後依警示或排程開 pull request，不是在審查變更時顯示影響。
安全主管要把數百個 code scanning 警示分給開發者，並由一位聯絡人追蹤進度。最適合的功能是？
單選題，選項：
正確答案：Security campaign，分組警示並指派負責人
解析：Security campaign 把一批警示分組分享給開發者，每個 campaign 有具名聯絡人，code scanning 警示還會自動觸發 Copilot Autofix 建議修復。
常見陷阱：委派繞過與警示關閉治理管的是「誰能放行」，不是「怎麼把累積的警示分派出去修復」。
下列哪些功能在變更進入預設分支或 repository 之前運作？（選 3 項）
複選題，選項：
正確答案：Dependency review，在 PR 檢視相依性變更；Push protection，在推送時阻擋 secret；Code scanning，檢查新增或修改的程式碼
解析：Push protection 在推送時攔截，code scanning 讓你在合併進預設分支之前修復問題，dependency review 在合併前顯示相依性變更的影響。Security campaigns 則是對已存在的警示做大規模修復。
常見陷阱：只看到「都屬於安全功能」就全選；題目問的是發生時間點，事後處理累積警示的功能不屬於預防導向。
某個 repository 已啟用 Dependabot alerts。一週內沒有人修改過 manifest 或 lockfile，今天卻出現一個新的 Dependabot 警示。最可能的原因是什麼？
單選題，選項：
正確答案：GitHub Advisory Database 新增了一則影響其相依性的 advisory
解析：Dependabot 在兩種情況下產生警示：資料庫新增 advisory，或 repository 的 dependency graph 變動。題幹說明相依性檔案沒有變，所以只剩新的 advisory 會造成新警示。
常見陷阱：相依性變動也是真實的觸發來源，但題幹已排除；程式碼沒改，警示仍可能因為外部資料庫更新而出現。
組織已啟用 delegated alert dismissal。一位只有寫入權限的開發者認為某個 code scanning 警示是誤報，想關閉它。接下來的流程是什麼？
單選題，選項：
正確答案：提出關閉請求，由擁有者或 security manager 核准或拒絕
解析：啟用後，有寫入權限的使用者必須提出關閉請求；組織擁有者與 security manager 可以核准或拒絕，也能自己直接關閉。核准就關閉警示，拒絕則保持開啟。
常見陷阱：前三個選項都是真實的行為，但分別屬於未啟用治理、警示指派與 push protection 的委派繞過；啟用 delegated alert dismissal 後，關閉才需要請求與審查。
把 repository 封存之後，其中仍開啟的警示會自動被關閉。
是非題：判斷敘述是否正確。
正確答案：正確
解析：官方在說明 security overview 的資料行為時指出，封存 repository 後，其中開啟的警示會自動關閉。
常見陷阱：容易以為封存只是唯讀標記，不影響警示；它會改變警示狀態，進而影響儀表板的歷史數據解讀。
稽核人員需要一份不會隨時間改變的去年第三季警示處置資料。官方建議的來源是？
單選題，選項：
正確答案：稽核日誌（audit log）中的事件紀錄
解析：Security overview 儀表板依 repository 目前狀態與警示歷史計算，同一段期間在不同時間查看可能得到不同結果；需要一致資料做合規或稽核時，官方建議改用稽核日誌。
常見陷阱：截圖看起來是固定證據，但它反映的是當下計算結果；來源本身會變，截圖就不是可重現的稽核依據。
資安團隊需要檢視組織內所有安全警示並設定安全功能，但組織不想授予他們所有 repository 的管理員權限。應該怎麼做？
單選題，選項：
正確答案：由組織擁有者把 security manager 角色指派給資安團隊
解析：Security manager 是組織層級的角色，由組織擁有者指派給任何成員或團隊。它包含所有 repository 的讀取權限、所有安全警示的寫入權限，以及設定安全功能的能力，但不需要授予 admin 權限。
常見陷阱：前三個做法都能給出某種權限，但不是過度授權，就是缺少檢視警示與設定功能的能力；security manager 正是為「最小必要權限」設計的角色。
關於 dependency review，下列哪些敘述正確？（選 2 項）
複選題，選項：
正確答案：顯示 pull request 中相依性的變動；需要先啟用 dependency graph 才能使用
解析：Dependency review 在 pull request 中顯示相依性的變更與安全影響，並依賴 dependency graph，所以需要先啟用。私有 repository 還需要組織擁有 Code Security 或 Advanced Security 授權。
常見陷阱：「公開 repository 預設可用」容易被擴大成「所有 repository 免費」；私有 repository 有授權條件。
團隊想讓使用者能驗證：他們用 GitHub Actions 建置的軟體，是由哪份原始碼與哪次工作流程產生的。應該使用哪個機制？
單選題，選項：
正確答案：Artifact attestations 功能
解析：Artifact attestations 是經密碼學簽署的聲明，說明建置的來源（原始碼與工作流程）或相關的 SBOM。它不保證軟體安全，只提供資訊讓你更有把握軟體沒有被竄改。
常見陷阱：Immutable releases 同樣和發布完整性有關，但它禁止發布後修改 release，並不說明軟體是怎麼建置出來的。