本指南旨在為Web3 行業的項目方提供安全建議。背景概述
2022 年12 月21 日，Web3 基礎設施提供商Ankr 發布事後報告，公佈因aBNBc 代幣漏洞導致500 萬美金加密貨幣被黑的調查結果。 Ankr 前團隊成員惡意地進行了供應鏈攻擊，插入惡意代碼包，只要項目方進行合法更新，該代碼包就能夠破壞Ankr 的私鑰。 Ankr 正在與執法部門合作，起訴這名前團隊成員並將黑客繩之以法。
隨著Web3 行業的不斷發展，近些年供應鏈安全形勢日益成為Web3 行業以及全球關注的焦點。而現代軟件開發依賴於各種第三方組件和外部服務，軟件供應鏈已經變得更加複雜和龐大，這也為惡意攻擊者提供了更多的機會來操縱和滲透軟件供應鏈，從而對企業和用戶的數據、資產造成巨大威脅。
最近幾年的事件表明，供應鏈安全漏洞可能導致嚴重的後果。惡意軟件和惡意代碼可以在軟件供應鏈的不同環節中植入，包括開發工具、第三方庫、雲服務和更新過程。一旦這些惡意元素被成功注入，攻擊者可以利用它們來竊取加密貨幣資產和用戶敏感信息、破壞系統功能、勒索企業或大規模傳播惡意軟件。
供應鏈安全
鑑於以上原因，慢霧安全團隊將從源碼安全，構建安全，傳輸安全，製品安全和部署安全這5 個關鍵環節的供應鏈安全提出安全建議。這5 個環節都需要圍繞輸入/產出可驗證，操作過程可自動化，在受控環境授權下進行，操作人員/系統都要經過安全認證這幾個緯度進行增強。
源碼安全
1. 代碼管理
使用GitHub 或者GitLab 等代碼版本管理方案，不僅可以方便高效的對項目的代碼進行管理，還可以在發現代碼後門等場景下快速定位提交代碼的角色。
2. 代碼提交
代碼的提交要保證完整性，確保經過安全檢測後的代碼被完整地提交，並且避免提交的過程中被植入其他非預期的代碼（存在漏洞的代碼或後門代碼）可以使用GitHub 的signing commits [1] 功能或GitLab 類似的功能gpg signed commits [2] 來保證提交的代碼的完整性，並且在合併代碼的時候需要可信的角色賬號用git merge -S –verify-signatures 驗證簽名 [3] [4]。
3. 代碼掃描
管理代碼的同時也需要對代碼的安全進行掃描，可以使用：SonarQube [5] 或Snyk Code [6] 對代碼進行靜態掃描 [7]，切記提交的代碼中不能包含有認證、隱私、私鑰等文件，敏感的API 或者認證的Keys 等等，開發者可以使用TruffleHog [8] 或GitHub 的secret-scanning [9] 工具對提交的數據進行安全掃描，來發現提交的代碼中的敏感信息（如：助記詞或私鑰信息）。
4. CI/CD
執行CI/CD [10] 可以幫助研發團隊實現自動化構建，測試，部署的流程，避免在集成和交付項目的過程有太多的手動操作，因為我們很難約束所有人都嚴格按照流程和標準實施操作。通過CI/CD， 可以更好地按照流程推進構建，測試，部署的操作，也有助於收斂服務器等相關IT 資產的訪問權限。 CI/CD 可以使用CircleCi [11] 和GitHub Actions [12] 等方案實現 [13]。
5. 物料安全
物料安全的通俗解釋即需要對接入的第三方服務，組件和依賴庫進行初步的安全評估，確保第三方風險管理可控，評估工作應盡可能包含：
- 提供方是否可靠。一般認為大廠出品的組件較為可靠，但是也有某些大廠提供的組件經常被披露安全漏洞，所以也需要根據組件/服務歷史上出現漏洞的頻率進行評估；
- 源碼是否開源。未開源的依賴庫可能會引入後門，所以應優先選擇知名，開源的庫；
- 製品是否可驗證。使用第三方提供的程序時，要經過checksums 的驗證；
- 對接方案是否完備。使用第三方服務，組件，依賴庫時要有完備的對接方案，確保在接入的時候盡可能地列出所有潛在的安全風險，並輸出安全性需求分析（列風險，出需求，這部分需要充分考慮第三方服務，組件，依賴庫出現異常或者被攻破後對項目的影響）。
要對物料安全進行監測，確保第三方服務，組件，依賴庫的風險可控可以從管理手段，技術手段，威脅情報3 個方面展開工作：
- 管理手段：可以藉鑑OWASP 的SCVS [14] 標準實施相應的基線和流程；
- 技術手段：安全人員可以使用Dependency Track [15]，Snyk [16]，Murphysec [17] 等產品對物料進行監測，研發人員可以在研發的過程中將類似Dependency Check，Snyk 的open source security management [18] 等工具集成到開發的工具或流程中，協助研發人員發現第三方依賴版本上的安全問題；
- 威脅情報：可以通過security.snyk.io，Vuldb 的漏洞情報第一時間對受到影響的項目進行升級或修復處理。
構建安全
大部分研發團隊採用手動對項目的程序或Docker 鏡像進行構建，構建完成後再手動推送到製品倉庫或生產服務器上，在這過程中存在許多的安全風險：
- 在研發人員本地電腦進行程序或Docker 鏡像的構建，這種情況下很難保證本地的物料是安全的；
- 人為進行程序或Docker 鏡像的構建，這種情況下很難保證構建人員不會引入非預期的代碼；
- 人為進行程序或Docker 鏡像的構建，就算有嚴格的安全流程，也很難保證構建人員會100% 遵循安全流程；
- 構建人員的本地環境很容易脫離安全管理的控制。
而通過在服務上部署自動化構建平台，可以很好的對構建流程進行安全管理，並且構建流程是由平台控制的，只要製定好構建的流程和規則，管理人員控制好平台的訪問權限，就能確保每次的構建流程都符合預期。
在編譯構建項目的應用程序或Docker 鏡像的時候，一般是採用Jenkins 平台進行自動化構建。使用Jenkins 等自動化構建平台時，需要嚴格按照官方的安全建議 [19] 進行配置，並且這類研發和運維的平台除了要做好平台賬號的訪問權限控制，還可以通過SSO 或MFA [20] 加強登錄驗證，在網絡層面上對訪問進行限制，可以限制僅使用公司的VPN 才能訪問。
通過部署自動化構建平台，使得程序或Docker 鏡像均由平台按照管理人員制定的流程和規則自動完成構建，減少人為操作可能不遵守流程和規則的情況，並避免了人為構建可能引入非預期代碼的風險。同時自動化構建平台還可以與代碼管理和代碼掃描聯動，如：使用jenkins-pipeline-with-sonarqube-and-gitlab 的方案 [21]，從代碼提交，代碼掃描，構建部署實施自動化操作和管理。
傳輸安全
在整個代碼管理，自動化構建的過程中遵循最小化權限控制和最小化網絡訪問，盡可能按照工作或崗位職責給每個人員角色分配最小化的權限，使用IP 白名單和VPN 的方式對網絡訪問進行限制，並且在構建後使用認證和通訊加密的方式將製品傳輸到製品倉庫 [22] [23] 中進行管理。
製品安全
製品即需要發布的穩定版本程序。構建時會將哈希和簽名信息放在程序的摘要裡，每當使用到製品的時候，需要驗證製品的簽名或哈希摘要信息。可以使用Cosign 或Notary 對製品進行簽名和驗簽，通常還需要使用製品管理平台（如：Nexus Repository Manager [24] 和Harbor [25]）進行製品的管理，同樣也需要遵循遵循最小化權限控制和最小化網絡訪問，可以使用Nexus Repository Manager SSO 方案 [26] 和Harbor SSO 方案 [27] 結合MFA 以及VPN 的方式控制登錄和訪問權限。
部署安全
部署分為首次部署和更新部署，首次部署之前要確保部署項目的服務器進行了基礎安全加固：
- 確保服務器是新開啟和初始化的，如果是雲服務器，那麼雲平台的賬號要做好權限劃分，並強制要求開啟MFA；
- 確保服務器僅開啟必要的端口，並且SSH 開啟IP 白名單和MFA 的限制；
- 確保服務器安裝了HIDS 或XDR；
- 確保服務器開啟了日誌記錄，可以使用CrowdStrike Falcon LogScale [28] 或Splunk [29] 對日誌進行收集；
- 開啟域名隱私保護，註冊後添加CDN 並綁定IP，避免真實IP 洩露。
項目部署最好採用自動化部署的方式（如：Jenkins 自動化部署 [30]），避免由於手動部署導致服務器的登錄權限出現管理紊亂的情況。
更新部署包含服務端程序和客戶端程序的更新，如何規範化更新操作可以參考theupdateframework [31] 的方案。
總結
在Web3 的發展過程中，供應鏈安全問題尤為重要。儘管Web3 的去中心化特性帶來了許多優勢，但也帶來了新的供應鏈安全挑戰。慢霧安全團隊希望通過發布《Web3 行業供應鏈安全指南》為Web3 行業的項目方提供安全建議，共同促進Web3 行業健康、安全、穩定地發展。
參考鏈接：
[1] https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
[2] https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/
[3] https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key
[4] https://www.chainguard.dev/unchained/keyless-git-commit-signing-with-gitsign-and-github-actions
[5] https://www.sonarsource.com/products/sonarqube/
[6] https://snyk.io/product/snyk-code/
[7] https://owasp.org/www-community/Source_Code_Analysis_Tools
[8] https://github.com/trufflesecurity/trufflehog
[9] https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partner-program
[10] https://resources.github.com/ci-cd/
[11] https://circleci.com/
[12] https://docs.github.com/en/actions
[13] https://about.gitlab.com/blog/2021/08/30/secure-pipeline-with-single-sign-in/
[14] https://github.com/OWASP/Software-Component-Verification-Standard
[15] https://dependencytrack.org/
[16] https://snyk.io/solutions/software-supply-chain-security/
[17] https://github.com/murphysecurity/murphysec
[18] https://snyk.io/product/open-source-security-management/
[19] https://www.jenkins.io/doc/book/security/
[20] https://plugins.jenkins.io/miniorange-saml-sp/
[21] https://gcore.com/learning/jenkins-pipeline-with-sonarqube-and-gitlab/
[22] https://gcore.com/learning/publishing-artifacts-to-nexus-using-jenkins-pipelines/
[23] https://www.kubesphere.io/docs/v3.3/devops-user-guide/how-to-integrate/harbor/
[24] https://www.sonatype.com/products/sonatype-nexus-repository
[25] https://goharbor.io/docs/2.7.0/working-with-projects/working-with-images/sign-images/
[26] https://help.sonatype.com/repomanager3/nexus-repository-administration/user-authentication/saml
[27] https://goharbor.io/docs/1.10/administration/configure-authentication/oidc-auth/
[28] https://www.crowdstrike.com/guides/linux-logging/
[29] https://www.splunk.com/en_us/home-page.html
[30] https://www.jenkins.io/doc/pipeline/tour/deployment/
[31] https://theupdateframework.io/security/#attacks-and-weaknesses
展開全文打開碳鏈價值APP 查看更多精彩資訊