本指南旨在為 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免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
