去年所發布的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等惡意相依項目攻擊。


熱門新聞

Advertisement