标准解读（四）｜金融科技软件供应链供需安全管理指南

2024年5月22日，联盟发布了《金融科技软件供应链供需安全管理指南》（T/ZFIDA 0001—2024）。该标准由工银科技有限公司牵头，中国电子科技集团公司第十五研究所、龙盈智达（北京）科技有限公司、中关村互联网金融研究院、北京比瓴科技有限公司共同发起。

该标准明确了金融科技软件供应链的安全保护目标，分析了金融科技软件供应链各安全保护目标面临的安全风险，并提出了安全视角下管理金融科技软件供应链的实践框架。标准详细阐述了供需双方再管理过程中需考虑的安全因素，并为金融机构和科技企业在软件供应链安全管理方面提供了切实可行的建议。

为了帮助成员单位更好地理解团体标准内容，联盟推出标准系列解读，本文章是系列解读的第四篇。上一篇主要介绍了团体标准中保障软件供应链安全的三大思路——加强供应商风险管理、软件供应链内容透明化、实施专门的测试和安全评估，并针对前两个解决思路，介绍了团标的相关对策和业内最佳实践（点击跳转）。本篇将讨论如何实施专门的测试和安全评估，最佳实践有哪些以及评估中需要注意的要点。

实施专门的测试和安全评估

提升软件供应商安全实践的可见性和软件内容的透明度，将显著提升组织管理软件供应链风险的能力。然而，在某些情形下，这些举措可能不足以全面评估特定软件或供应商带来的风险。对于处理高度敏感数据或支持高风险关键功能的系统，应当考虑更加积极的安全评估。同样，有些供应商尽管被认为具有高风险，但组织出于各种原因仍需与之合作，这种情况也可执行实施专门的测试和安全评估，以保障组织的安全。

团标在进行安全测试和评估中重点指出：

供方宜配合需方建立可追溯台账，对整个使用过程进行记录、检测和维护。
供方宜配合需方根据需求、协议等定期检查软件是否受到篡改。
供方和需方宜制定和实施防盗版的策略和规程，检测并防止仿冒组件进入软件。
供方宜明确相关知识产权要求，并在交付时进行相应的安全检查和审核，避免供需双方因知识产权问题导致的法律风险。
供方宜建立构建、开发、测试、发布、安装、配置和维护工具和设备白名单，采用安全检测、正版授权验证、官方完整性校验等措施进行白名单准入控制，并记录相关风险信息。

一、相关检测工具

恶意软件或恶意代码的识别越来越普遍，攻击者可以注入恶意代码，被最终用户使用，并能够通过供应链迅速传播并导致广泛的数据破坏和隐私泄露，严重影响个人和机构的运作和声誉。因此，实施专门的测试和安全评估，识别恶意软件、恶意代码及敏感信息显得尤为迫切。这些软件通过深度扫描和实时监控，能够有效预警和阻止潜在威胁，从而保障用户数据安全与系统完整性。以下是常见的六类检测工具和平台，提到的各种工具应与其他传统的测试形式（如渗透测试）结合考虑。

①软件成分分析

软件成分分析（Software Composition Analysis，SCA）工具用于分析软件应用程序中使用的第三方开源组件和其他依赖项，可以用于辅助软件供应链安全体系建设。上一篇（点击跳转）我们提到，SCA工具能够检测和识别所有的软件成分，可用于生成SBOM。同时，它也可以对这些软件成分进行漏洞扫描和许可证风险评估，帮助用户及时修复漏洞，提高软件安全性和合规性。

具体来说，软件成分分析产品可以在以下几个方面为金融行业软件供应链安全提供帮助：

发现潜在的漏洞和安全问题：软件成分分析产品可以检测软件应用程序中使用的开源组件和其他依赖项中的漏洞和安全问题，并提供相应的修复建议。
识别风险：软件成分分析产品可以帮助金融机构识别风险，并评估这些风险对软件供应链的潜在影响。
提高透明度：软件成分分析产品可以提高软件供应链的透明度，使金融机构更好地了解其软件应用程序中使用的所有组件和依赖项，并更好地管理这些组件和依赖项的漏洞和安全问题。

常见的SCA的两种检测模式

1.依赖分析

基于依赖分析的软件成分分析关注软件应用程序的依赖关系，包括直接依赖和间接依赖，通常通过扫描软件包管理器中的依赖关系和元数据来进行。

软件成分分析识别应用程序所依赖的外部组件和库，分析每个依赖项的组件信息，包括版本号、开发者、许可证等，同时与已知的漏洞数据库进行比对，以确定组件中是否存在已知的安全漏洞。通过检查依赖项的版本、安全补丁和更新状态，可以确定应用程序的安全性。

2.同源分析

基于同源分析的软件成分分析是通过提取软件源代码、二进制文件的特征，并且与组件数据库进行对比。它分析每个组件的信息，包括版本、开发者、许可证等，与已知的漏洞数据库进行比对，以检测组件中是否存在已知的安全漏洞。这种方法依赖于特征提取算法的准确性，以及组件数据库的准确性，通常误报率更高，但是可以对二进制文件进行成分分析。

②静态应用程序安全测试

静态应用程序安全测试（SAST）是一种用于发现源代码潜在质量问题、安全问题的自动化技术。它在软件开发生命周期的早期阶段，通过分析源代码来进行静态检测。

静态应用程序安全测试可以帮助发现代码中的潜在安全漏洞，如缓冲区溢出、代码注入、跨站脚本等。它可以提前发现和修复这些漏洞，从而减少后期漏洞修复的成本和风险。一些静态应用程序安全测试同时提供集成开发环境（IDE）插件，能够在代码编写过程中提供实时反馈，帮助开发人员及时纠正潜在的安全问题。

在使用第三方组件或库时，通过对这些组件进行静态应用程序安全测试分析，可以检查是否存在安全漏洞，并验证代码是否符合安全编码准则。这有助于确保第三方代码的安全性，并避免引入不安全的组件。

③交互式应用安全测试

交互式应用安全测试（IAST）是一种结合静态和动态测试技术的应用安全测试方法。交互式应用安全测试能够动态分析应用的执行路径，与应用进行交互，并监控其行为。这使其可以发现那些在静态分析中难以检测到的漏洞，例如运行时漏洞和配置错误。

在软件供应链中，通过将交互式应用安全测试与其他测试方法（如SAST和SCA）结合使用，可以提供更全面的安全测试覆盖。这有助于发现和修复潜在的安全漏洞，确保软件供应链中的应用的整体安全性。

④硬编码敏感信息检测

硬编码敏感信息检测（Hard-coded Secrets Detection）工具可以静态的扫描源代码，搜索源代码中的字符串，并尝试识别敏感信息的模式和格式，定位潜在的硬编码敏感信息（例如密码、API密钥、数据库凭据等），提高应用的安全性。

硬编码敏感信息的明文存储容易导致信息泄露，尤其当源代码不受适当的保护时，使用硬编码敏感信息检测工具对代码进行评估和审核，防止敏感信息的滥用，防止代码中硬编码敏感信息泄露给第三方。

将硬编码敏感信息检测工具集成到持续集成和持续交付（CI/CD）流程中，可以实现自动化的安全检查。这样，每次构建和部署过程中都会对代码进行检测，以确保不会出现硬编码敏感信息的问题。

⑤容器与K8s安全

容器和Kubernetes（简称K8s）是构建云原生应用的事实标准，Gartner预测在2027年，全球超过90%的组织将在生产环境允许容器化应用。在谈到容器和K8s的安全性时，通常有以下几个方面需要考虑：

容器镜像的安全性：容器镜像是容器化应用的基础，因此其安全性至关重要。在构建和管理容器镜像时，应确保从可信的源获取基础镜像，并定期更新它们以应对安全漏洞。另外，需要避免在容器镜像中包含敏感信息，并采用最小化镜像的原则，减少潜在的攻击面。
容器运行时的安全性：容器运行时负责在主机操作系统上创建和管理容器。确保容器运行时本身是最新的版本，并配置适当的安全设置，例如命名空间隔离、资源限制和访问控制。此外，对于多租户环境，应采取必要的措施来隔离不同的租户，以防止恶意容器之间的相互干扰。
网络和通信安全性：K8s作为容器编排系统，负责管理容器之间的网络通信。确保K8s集群中的网络通信受到适当的安全保护是至关重要的。这包括使用网络策略（Network Policies）来限制容器之间的流量，并配置网络插件以实现网络隔离和加密传输。
访问控制和身份验证：K8s提供了访问控制和身份验证机制，用于限制对集群资源的访问和确保只有授权的用户或服务可以进行操作。这包括使用角色和角色绑定来定义权限，并配置适当的身份验证机制，如基于令牌的访问和集成外部身份提供者。
监控和日志审计：在容器和K8s环境中进行监控和日志审计是发现和响应安全事件的重要手段。通过收集和分析容器和K8s集群的日志，可以及时检测到异常活动，并采取相应的措施来应对潜在的安全威胁。

容器镜像安全扫描能力

1.基础镜像评估：对所使用的基础镜像进行评估，检查其是否来自官方源、是否有已知的安全问题等。

2.成分分析：对容器镜像中的软件组件和库文件进行分析，标识出容器镜像中存在的已知漏洞，以便及时修补或采取其他安全措施。

3.恶意软件检测：检测容器镜像中是否包含恶意软件或其他恶意组件。

4.全配置检查：检查容器镜像的配置是否符合安全最佳实践，是否存在弱口令等安全问题。

⑥建立安全自动化体系

应用安全编排和关联（Application Security Orchestration and Correlation，ASOC）是一种综合性的应用安全管理产品，可以用于辅助软件供应链安全体系建设。Gartner对ASOC的描述指出，ASOC采用了自动化配置的方式，将应用安全工具与软件开发环境进行整合，如软件成分分析工具。它可以自动化应用程序安全任务，并为各种安全数据源提供统一的视图和分析。ASOC产品的主要目的是通过协调和协作来提高应用安全性，并提供整个应用生命周期的安全保障。

在软件供应链安全场景下，ASOC产品可以帮助企业在开发、测试和部署软件应用程序时更好地管理安全风险和漏洞。以下是ASOC产品在软件供应链安全场景下的应用：