本文將闡述 NIST 最新指南中的關鍵建議,以及其與現代組織進行軟體開發和發布之間的相關性。
文/Chris Hughes·譯/酷魯
軟體供應鏈(Software supply chain,SSC)攻擊持續成為網路安全產業中討論最多的話題之一,這是有充分理由的,因為根據一些資料顯示,這類攻擊在過去三年裡的次數上升了 742% 以上。
隨著這類攻擊的持續成長,組織不斷尋找方法來緩解 SSC 攻擊的風險,各種產業組織也持續發布指南以幫助組織。對此,美國國家標準技術研究院(US National Institute of Standards and Technology,NIST)發布名為《在 DevSecOps CI/CD 管線中的軟體供應鏈安全整合政策》的 800-204 特刊(SP 800-204)。
[ 熱門精選:網路攻擊加增!資安長角色急轉彎!如何樹立一個強大合規文化? ]
當今的軟體開發和發布公司更頻繁地利用雲端原生環境和技術來實現這一目標,例如持續整合/持續發布管線(CI/CD pipeline)與開發營運安全(DevSecOps)方法的運用。
這種技術和實踐的結合使組織能夠透過軟體開發生命周期(software development lifecycle,SDLC)來簡化軟體開發流、自動化任務,並整合安全工具和實踐,進而緩解可能的風險。也就是說,當這些環境和技術沒有得到妥善的保護時,就有可能遭到漏洞攻擊,對那些處於軟體供應鏈下游的軟體使用者造成所謂的「下游安全衝擊」(downstream impact,DSI)。
安全武裝組織以緩解軟體供應鏈風險
NIST 指南致力提供保護組織的建議,以減輕這方面的風險,並加強軟體供應鏈安全。在 CI/CD 流程中保護軟體意味著確保軟體在建置(build)、測試(test)、打包套件(package)和部署(deploy)等各個階段中都不會遭到入侵攻擊。
正如 NIST 所指出的,所謂 SSC 不僅包括特定活動的產出,還包括為建置與發布軟體而執行之各種活動不會受到入侵攻擊的保證,並且有能證實這一點的支持性產出物(Arifact)和證明。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ,與全球 CIO 同步獲取精華見解 ]
由於供應鏈為惡意行動者提供了規模經濟的效益,SSC 攻擊將會持續增加。攻擊者能夠鎖定廣泛採用供應鏈的供應商、服務或開放原始碼軟體(OSS)元件或專案,而不是針對單一組織進行漏洞攻擊,進而對大量受害者造成所謂大規模的下游安全衝擊。
SSC 防禦面的部分挑戰在於,現代 SSC 涉及許多不同的利害關係者、組織、產業、技術和社群,這讓實施統一的治理和安全之道變得極其困難。
軟體供應鏈中的風險因素
NIST 定義出 SSC 攻擊的三階段情境:
- 產出物、步驟或惡意行動者入侵階段。
- 傳播階段。
- 漏洞攻擊階段。
在處理現代軟體開發環境時,有各種不同的實體和風險因素在起作用。這些因素包括開發環境、威脅行動者、攻擊途徑、目標以及正在進行的漏洞攻擊類型。這些因素在不同的組織和產業中可能有所不同,但最終都會在任何 SSC 入侵情境中發揮作用。
[ 推薦文章:軟體供應鏈安全的要角與良方-SBOM ]
對於尋求執行 SSC 攻擊的惡意行動者來說,開發人員環境是主要的攻擊途徑。當前開發環境尤其因為現代分散式勞動力、自帶裝置上班(BYoD)情境以及軟體即服務(SaaS)和自代管原始碼管理系統(self-hosted source code management systems)的結合而變得更具挑戰性。組織必須採取措施來緩解開發環境、開發人員帳號及其相關端點入侵所帶來的可能風險。
來自內外部的軟體供應鏈攻擊
當前威脅行動者包括外部和內部攻擊者的組合。所謂外部攻擊者,其可能因發動惡意活動的原因不同而有所不同,例如基於從網路活動到尋求影響外國對手及其國家機構與關鍵基礎設施的國家級攻擊行動等不同理由。
所謂內部攻擊者,可能包含了由不滿抑或勒索及賄賂等因素驅動的惡意內部人員。這些攻擊通常利用各種攻擊技術來入侵供應鏈中的軟體,例如網路釣魚、惡意軟體和社交工程等技術。
[ 推薦文章:支援軟體供應鏈安全所需的 10 大類別安全工具 ]
威脅行動者可以採取的攻擊途徑範圍很廣,這取決於目標環境、組織和情境狀況。這些攻擊途徑可能包括惡意軟體、社交工程或基於網路和實體的攻擊。由於每種不同的攻擊途徑都需要相應的緩解控制機制/技術,這尤其讓大型複雜組織很難每每緩解所有攻擊途徑。
攻擊目標包括原始碼、憑證和敏感資料。漏洞攻擊的類型因不同活動而有所不同,包括漏洞和惡意軟體的注入、憑證竊取和將惡意程式碼注入到儲存庫(repository)中等惡意活動。NIST 列出了一系列穩健的緩解措施,從修補程式管理和存取控制等基本活動到稽核與監控,並且與適用的監管框架保持一致。
CI/CD 管線 ─ 信任、目標和安全成果
現代 DevSecOps 環境使用 CI/CD 平台和技術來促進迭代軟體開發和發布。隨著軟體經過建置、打包套件、測試和部署的各個階段,這些階段會產生詮釋資料(Meta Data),這些詮釋資料可以促進對軟體來源以及生產軟體所採步驟和措施的保證。
任何步驟以及底層 CI/CD 環境和平台的入侵,都可能對所生產和分發之軟體產出物的完整性構成下游安全衝擊。
組織必須對內部開發的(第一方)程式碼以及第三方元件(例如開放原始碼軟體)採取安全措施,這些元件日益構成現代軟體的主體,至少從原始碼的角度來看是如此。
組織最終希望確保攻擊者無法篡改軟體生產流程,引入惡意軟體更新,或危害 CI/CD 管線產出物和活動的完整性。NIST 提供下表,展示了典型 CI/CD 環境中需要信任的產出物,以及這些產出物通常常駐/依賴的儲存庫:
產出物 | 儲存庫 |
---|---|
第一方程式碼 ─ 原始碼或二進碼 | 原始碼管理(SCM) |
第三方程式碼 ─ 開放原始碼或商用 | 語言、容器等產出物管理員 |
建置 | 建置儲存庫 |
打包套件 | 套件儲存庫 |
CI/CD 管線中的軟體供應鏈安全
既然我們已經討論了可信 CI/CD 管線中涉及的一些背景、安全目標與實體,那麼接下來就讓我們一同來看看 NIST 在其指南中強調的一些特定 SSC 安全活動。
有鑑於 NIST 發布的 800-207《零信任架構》刊物,NIST 在此宣傳零信任原則也就不足為奇了。其中所引用的建議包括為系統調度人員(system operator)定義角色,對應特定權限,並實施與角色存取控制(Role-Based Access Control,RBAC)概念相一致的最低權限存取(least-privileged access)原則。只要特定使用者的帳號或資產遭到劫持,這樣的活動就可以緩解風險。
NIST 還建議自動化靜態應用程式安全測試(Static Application Security Testing,SAST)和動態應用程式安全測試(Dynamic Security Testing,DAST)的使用,以及透過基礎設施即程式碼(Infrastructure-as-Code,IaC)與政策/配置即程式碼(policy/configuration-as-code)等技術來聲明式地定義應用軟體程式碼和 CI/CD 活動的開發和部署,這些技術可以出於安全和法規遵循目的來指定運行時間設定(runtime setting)。CI/CD 管線的工作流程也必須是安全的,包括來自儲存庫中產出物的建置、推/拉操作以及軟體更新或程式碼提交。
NIST 對建置的建議
在建置方面,建議包括關鍵活動,例如指定建置政策和使用隔離的建置平台,以及對執行建置活動的人員指定權限。組織還應充份利用政策執行引擎,並確保在軟體建置過程中產生安全建置過程的證據和證明。
這些可能包括對環境、過程、材料和所涉及產出物的證明。NIST 建議使用雜湊技術來含括最終建置產出物、檔案、函式庫和製作最終產出物的事件。接著建議對該證明進行簽章並將其安全儲存在可用來證明政策遵循(policy compliance)的地方。這樣做可以幫助證明軟體是由授權實體及工具建置的,並且與定義的政策和法規遵循需求相符合。
[ 推薦文章:NIST 公告網路安全框架CSF 2.0 版 ]
除了確保建置活動的安全需求外,NIST 還建議確保 SCM 儲存庫上推拉操作的安全。這包括開發人員從儲存庫中提取程式碼,對其進行修改,然後將程式碼推送回儲存庫,這其中的每一個過程都存在被篡改的機會。建議包括對產出物進行自動化安全檢查,以確保原始碼來源的可信度,並要求明確批准想從儲存庫中進行提取和推送操作的所有外部協作人員。
惡意行動者將惡意程式碼植入儲存庫
圖 1 為來自 Francois Proulx 的圖片展示了惡意行動者如何採取各種行動來獲得未經授權存取 GitHub 儲存庫的權限,並向儲存庫提交惡意程式碼。
在其他重要的建議中,NIST 建議在軟體更新期間保持證據生成的完整性,確保程式碼提交的安全性,並確保 CD 管線中的工作流程的安全性。攻擊者可能會想要清除或篡改軟體更新的痕跡,以免遭到調查和偵測性控制。
此外,為確保程式碼提交不會引入惡意程式碼或充滿安全漏洞的程式碼,NIST 建議在 CI/CD 管線中使用支援廣泛語言的 SAST/DAST 工具,並使用 SCA 工具來驗證 OSS 元件和相依性(dependencies)的安全性。
由於 CD 管線圍繞著工作流程運行,而且許多現代環境都在使用容器化等技術,NIST 建議確保部署的容器確實是由定義的建置流程生成的,而且它們已經根據組織的漏洞管理要求完成了漏洞掃描。
最後,有鑑於最近業界出現大量引人注目的機密外洩事件,NIST 建議組織掃描程式碼中是否存在諸如密鑰或存取令牌等機密,這些機密可能會被惡意行動者惡意濫用。
(本文授權非營利轉載,請註明出處:CIO Taiwan)