開源專案軟體安全掃描工具Scorecards更新擴大檢驗項目

去年所發布的Scorecards專案，現在Google與開源安全基金會（Open Source Security Foundation）社群合作，發布了Scorecards v2，這個新版本添加了新的安全檢查，對開源專案擴大評分，同時也簡化資料取得的方式，使得這些資料更易於分析。

Scorecards專案的目標，是要能夠對開源專案自動產生安全分數，協助使用者選擇可信且安全的解決方案。Scorecards定義了一個初始評估標準，該標準以完全自動化的方式，對開源專案產生計分卡，每個計分卡的檢查都是可採取行動的，像是定義明確的安全策略、使用模糊測試、靜態程式碼分析工具的持續測試覆蓋率，以及程式碼審查過程等，這些安全檢查回傳布林值和可信分數。

Google提到，由於目前有非常多的軟體仰賴開源專案，使用者需要一種簡單的方法，來判斷他們所使用的相依項目安全性。在維護專案供應鏈時，Scorecards自動評估相依項目可能帶來的風險，可以減少用戶持續評估專案所付出的勞動與人工，並且根據這些資料，做出相對應的決策。

Scorecards專案自發布以來持續更新，Google提出了解、預防和修復框架，以覆蓋更多的檢查項目，這些項目包括惡意貢獻者，專案存在具有惡意意圖或是被盜帳號的貢獻者，可能在程式碼中偷藏後門，程式碼審查有助於減輕這類的攻擊，而藉由新的分支防護檢查，開發人員可以在提交程式碼之前，驗證專案是否強制執行開發人員程式碼審查。目前因為GitHub API的限制，這類檢查只能由儲存庫管理員執行，而其他第三方儲存庫，則需要改用資訊較少的Code-Review檢查代替。

即便開發人員審查和同儕審查機制，能夠最大程度避免易受攻擊的程式碼，在未被發現的情況下進入程式碼控制中，因此啟用持續模糊測試和靜態程式碼分析顯得重要，能夠在開發生命周期中提早發現問題，因此Scorecards v2也會檢測專案是否在CI/CD系統中，使用模糊測試和靜態程式碼分析工具。

Google提到，諸如GitHub專案常用的CI/CD解決方案GitHub Actions，可能接受不受信任的用戶輸入，使建置系統出現漏洞，這代表攻擊者可以製作惡意的拉取請求，以獲得對特權GitHub權杖的存取權限，使得將惡意程式碼推送到儲存庫的過程不需要受到審查。為了降低這種風險，Scorecards權杖權限預防檢查，現在會驗證GitHub權杖設置，專案需要預設GitHub權杖為唯讀，以遵循最小權限原則。

錯誤的相依項目設置，也可能使得開源專案產生安全破口，雖然Scorecards能夠評估軟體來降低風險，但是反面模式（Anti-Pattern）可能破壞Scorecards的評估能力，像是簽入（Checked In）無法被簡單驗證的二進位檔案，因此現在Scorecards提供二進位構件檢查來進行測試。

另一個反面模式則是使用curl|bash來動態拉取相依腳本，由於加密雜湊值能夠確認已知的相依項目，當雜湊值發生變化，則建置系統便會拒絕建置。固定相依項目的機制，在編譯、Dockerfiles和CI/CD工作流程，都能發揮良好的效果，而現在Scorecards會使用Frozen-Deps項目，檢查這個反面模式，發現像是CodeCov等惡意相依項目攻擊。