背景概述

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