4.3 软件供应商风险评估

源自软件供应商的风险可归为两大类，一是供应商引入的安全风险，如软件断供、应急安全响应不到位等；二是供应商软件引入的安全风险，如许可兼容性带来的法律风险、漏洞风险等。根据上述两类风险，下文为企业提供风险评估说明以指导企业对软件供应商进行风险评估，并提供对应风险的规避、解决和缓解方案。

4.3.1 供应商资质评估

2022年，由于美国政治制裁因素，俄罗斯开发者遭到GitHub封号，被禁止访问并被删除托管代码；多家公司宣布暂停或永久退出俄罗斯市场，AMD、IBM和英伟达等公司暂停了对俄罗斯的敏感技术出售。2018年以来，美国将海光信息、华为等中国高科技公司先后列入“实体清单”，对中国相关企业在半导体、数据库和通信等重要信息技术领域的发展进行打压。如今国际形势动荡，单边制裁时有发生，在全球主流开源组织、社区、开源代码托管平台都由欧美国家相关组织控制的境况下，开源软件面临着极高的断供风险。

软件供应商资质评估（见图4-3）在供应商引入阶段至关重要。供应商资质评估，包括对供应商的综合实力及供应软件的评估，能够有效管控来自供应商的断供风险、防御其自身经营风险情况。

1）掌握供应商信息

为了确保企业能够拥有较为稳定的供应链，提高企业的综合竞争力，在供应商引入的选择环节，需要对软件供应商经过多方面的综合考察分析，构建系统化、结构化的软件供应商评估模型。其关键在于从不同维度对软件供应商进行评估，通过考察软件供应商的综合实力，选择最合适的合作伙伴。

（1）企业资质。评估软件供应链上的第三方供应商是否能够提供软件安全开发能力的企业级资质，是否具备国际、国家或行业的安全开发资质，在软件安全开发的过程管理、质量管理、配置管理、人员能力等方面是否具备一定的经验，是否具有把安全融入软件开发过程的能力。

（2）财务实力。评估软件供应商的财务能力及稳定性，包括考察软件供应商融资数额、市场份额、利润等财务实力，选择财务实力雄厚的供应商有助于保障供应商所提供服务的稳定性和可靠性。

（3）质量承诺。评估软件供应商的相关软件产品是否符合国家及行业标准要求，信息安全和数据保护控制流程必须遵守法律、监管要求或合同义务及任何行业标准的信息安全要求。选择质量过硬的软件产品、对软件产品具有较高质量承诺的供应商，能够极大地减少后期软件使用过程中可能发生的质量问题，减少频繁返厂维修更新的可能性。

（4）技术储备。评估软件供应商是否拥有自主研发能力及自主技术知识产权，对科技知识是否进行不断的积累和及时更新，对企业提高技术水平、促进软件生产发展是否开展一系列的技术研究。选择技术能力过硬、技术储备富足的供应商，能够保障软件产品优质、高水准，并能保证软件产品技术与时俱进，保障软件的先进性、对于不断更新迭代的市场和时代需求的适应性。

（5）合作能力。评估软件供应商是否拥有高效的沟通渠道及全面的解决方案，选择合作能力强、沟通高效的供应商，能够带来较好的合作体验，有利于构建良好且持久、坚固的供应关系。

（6）软件交付能力。评估软件供应商在整个软件及信息服务交付的过程中，是否能满足软件持续性交付的要求，选择交付能力强、能够持续交付的软件供应商，能够较大程度上减少供应商断供风险，避免软件交付延误业务运营上线。

（7）应急响应能力。评估软件供应商从软件开发到运营阶段是否持续实行实时监控机制，是否有利用适当的网络和基于端点的控制来收集用户活动、异常、故障和事件的安全日志，是否具有足以保障业务连续性的恢复能力，是否有相应的安全事件应急响应团队及对应的应急预案，以防止业务中断或减轻相关影响。选择应急响应能力强、预备事前预案措施的企业，能够为软件上线运营后的安全保驾护航，即使突发安全事件，供应商也具备采取应急措施的能力与经验，能够极大限度地降低企业利益损失。

（8）服务支撑能力。评估软件供应商的售前服务能力、培训服务能力及售后维护服务能力、客户关系管理等方面能力是否满足企业的要求，在合作期间是否能够按时、按需提供产品操作手册、用户文档等；严格检查供应商提供的服务水平、信息安全服务等协议，合作期间是否可以始终如一地提供高水平的质量和服务。选择服务支撑能力强的企业，因为此类企业能够在软件开发全生命周期，持续性提供服务、跟进需求开发，维持服务的高质量和高水平。

（9）创新能力。评估软件供应商的综合创新能力，包括技术创新能力、研发能力、产品创新能力及生产创造力等，选择具备创新能力的供应商，能够保证软件的更新与创新活力，不断优化软件产品质量。

（10）制度管理能力。评估软件供应商是否拥有完善的内部管理制度流程、有效的风险防范机制及是否对员工定期进行安全培训等，对供应商内部安全开发标准和规范进行审查，要求其能够对开发软件的不同应用场景、不同架构设计、不同开发语言进行规范约束，审查软件供应商对其自身信息的安全保密程度。选择制度管理完善、具备有效风险防范机制的企业，不仅能够管控供应商自身安全风险，还能保证供应商提供的软件产品的质量与服务质量。

（11）历史纠纷。了解供应商是否曾经涉及重大纠纷、诉讼或违约事件。可以查询法院公开记录、媒体报道、行业论坛等，以获取与供应商相关的信息。

（12）合规经营。核实供应商是否符合相关法律法规和行业标准。这可能包括营业执照、税务登记证、资质证书、专利和知识产权等。可以通过工商部门、税务部门、知识产权局等机构查询相关信息。

（13）软件适用性。评估软件在开发部署及动态运行时的适用性、是否可以持续满足新的需求，评估产品能否在各环节满足多种使用场景与多种身份人员的使用需求，选择适用性佳的软件产品。

（14）企业文化。考察企业文化理念，企业文化理念深刻影响着企业人员的工作态度。

（15）认证资料。考察企业相关领域认证证书，验证企业软件实力证明。需参考行业领域内具有权威性组织、结合目前对供应商资质提出明确要求的政策文件，外加其他与企业安全能力挂钩的国家认证评测体系，如系统等级保护评测，针对备案证明和评测证书等评审的信息系统保障评测，针对信息安全人员评测的CWASP CSSD/CSSP、CISSP、CISP等评测标准，包含对工程服务能力评测标准的ISO/IEC 21827 SSE-CMM等，选择具有权威性组织认证、符合国际及国家政策标准的供应商和软件产品。

（16）项目经验。软件供应商具备的项目经验、合作双方协议合同的真实性关系着多方面问题，尤其涉及法律相关风险。企业需对供应商历史合同进行周密的考查，确保合同条款的真实性，检查有无可疑的隐藏条款。

（17）企业信誉。企业需对供应商进行软件产品口碑、供应商口碑考察，可从已部署使用软件的友商处了解其口碑，选择具有良好口碑、业内满意度较高、合作经验较多的供应商，过滤业内风评较差的供应商及产品。

（18）国家政策敏感因素。在选择供应商时需考虑国家政策等敏感因素，对于关键信息基础设备，应尽量避免使用国外供应商的进口软件，防范如俄乌事件中发生的国际制裁、投毒、断供等安全风险；同时需评估供应商是否尊重相关的法律法规和标准，考察供应商产品在数据隐私、知识产权、电子商务等方面的合规性。

（19）团队人员考察。对供应商团队人员进行考察，包括但不限于团队人员数量、人员素质水平、人员技术水平、服务支撑能力、团队应急响应能力、人员是否被列入信用黑名单等。

2）软件供应商产品评估

供应商资质评估阶段还需对供应商提供的产品进行多维度评估（见图4-4），以保证软件产品的安全性，减少可能引入的软件风险。

（1）软件技术交流。了解供应商软件产品的技术构成，如技术框架、使用第三方组件情况、代码自研率等，防范IT中断或故障风险、数据和隐私风险、合规风险、供应商更换风险等。要求供应商提供符合“最小要素”要求的细粒度SBOM文件，以用于软件组成成分审计评估，对可能存在的漏洞、合规风险进行严重性等级评估；同时使用软件供应链安全检测技术，对供应商软件产品进行安全性检测。最后，建立供应商应用技术清单，形成资产台账与技术检验报告并备案。

（2）软件功能交流。基于企业核心业务需求，对供应商软件产品进行软件功能交流。供应商提供的软件产品不仅需要满足企业功能需求，更要满足易用性、适用性、多场景覆盖及无缝接入开发流程的需求，尽可能以“零存在感”融入软件全生命周期中。

（3）解决方案考察。针对供应商提供的解决方案进行真实性、专业性、实用性多维度评审，并结合供应商软件产品，对其提供的解决方案进行落地实战性测试。

（4）软件使用案例。考察供应商软件产品的真实使用案例，了解软件使用过程中潜在的问题，如安全问题、更新频率、服务支持、应急响应等。

（5）项目落地考察。对供应商已落地实践的项目进行全面考察，确定其软件落地实践后，能否满足企业实际需要，是否履行协议合同中所约定的职责，并预估落地实践后成效与计划目标间的差距。

（6）多业务场景试用。供应商软件需在多业务场景进行测试，判断其是否满足技术、功能需求，考察其与各场景融合适应情况。尽可能选择能够无缝融入各业务场景的软件产品，降低使用者的学习成本。

（7）需求部门确认。软件产品经需求部门试用后，确认软件产品是否满足技术需求、功能需求等。并最终评估软件产品建设成本，在符合评审结果的供应商名单中，选择最适合企业的供应商合作。

3）供应商资质评估参考表

在明确软件供应商安全治理总体方针的前提下，从多维度对软件供应商资质进行评估，由此可以形成一个相对全面、详备、多维度的软件供应商资质评估表，如表4-1所示，以作为评估选择软件供应商、采购软件产品的参考供企业内部使用。

使用软件供应商资质评估表前，需确定每个维度的总分分值和分数判定细则，建议企业根据自身需求、各维度重要程度、对业务影响程度，合理调整各维度总分分值，如多场景试用可将分值上限调高、占总比分比例加大，企业文化分值上限调低、占总比分比例低；分数判定细则建议归纳为具体详细规则，如在评估时，对供应商及其产品，根据评分细则，予以赋分制，最终选择分值最高的项目。

对该评估表需做归档留痕，便于后续整理供应商资料及其软件产品资产台账。同时，还需依照企业发展、业务需求、政策制度，持续维护、更新和完善该评估表。

4.3.2 供应商安全评估

软件供应商安全评估是作为引入供应商及后续软件安全管控的核心环节和保障前提。在该环节中，应对软件供应商及其软件开发内部供应链完整性、安全性进行综合考量评估。

4.3.2.1 供应商安全检测评估方案

软件供应商安全评估，可参考《关键信息基础设施ICT供应链安全风险评估指标体系研究》中提出的关键信息基础设施ICT供应链安全评估指标体系（见图4-5）。

该体系从指标框架、指标体系、指标释义（见表4-2）和实施过程等方面出发进行阐述，围绕关键信息基础设施ICT供应链涉及的各个方面，衡量供应链安全性、输出可能的风险点，作为评价关键信息基础设置ICT供应链安全程度的依据，推动关键信息基础设施ICT供应链安全的检测评估工作开展。

4.3.2.2 供应链完整性级别评估

2021年以来，针对软件供应链上游、软件供应商的攻击事件呈上升趋势。在供应商软件开发和供应链部署、交付的过程中缺少全面的、端到端框架来定义和减轻整个软件供应链中的威胁，并提供合理的安全保障方案。面对近年来的黑客攻击（如SolarWinds、Codecov），如果软件开发人员和用户采用类似供应链的安全框架，其中一些攻击可能会被阻止。

在这一供应链背景和安全需求的催生下，谷歌提出的解决方案是软件开发的供应链级别（Supply chain Levels for Software Artifacts，SLSA），是一个端到端框架，用于保证整个软件供应链中组件的完整性。这一框架灵感来自谷歌内部的“Borg二进制授权系统”，并且已经在谷歌内部使用了8年多，强制托管谷歌所有生产工作负载。SLSA的目标是改善行业状况，尤其是开源软件安全状况，进而抵御最要紧的供应链完整性威胁。

SLSA框架主要解决了三个问题：

（1）软件生产商希望确保其供应链的安全，但不知道具体的方法。

（2）软件消费者希望了解并限制他们在供应链上受到的攻击，却没有办法做到这一点。

（3）单纯的工件签名只能防止企业所关心的攻击的一个子集。

SLSA可以作为软件生产商和消费者的一套指导原则，提供软件工件直接供应链的完整性强度，即其直接来源和构建步骤。同时，SLSA制定的4个级别（见表4-3）使企业、消费者、供应商都能快速判断软件产品的完整程度，并了解在生产过程中软件产品已经抵御了哪些攻击。

SLSA主要侧重以下两个原则：

（1）非单方面。没有人可以在没有明确审查和批准的情况下，在软件供应链的任何地方修改软件工件，至少需要有一个其他“受信任的人”。

（2）可审计。软件工件可以安全、透明地追溯原始的、人类可读的来源和依赖关系，其主要目的是对来源和依赖关系进行自动分析，以及便于临时调查。

表4-4是SLSA等级要求项。

【源码】工件的最高级别源码要求，即包含构建脚本的源码。

版本控制：对源码的每个更改都会在版本控制系统中进行跟踪，版本控制系统会识别谁进行了更改、更改的是什么及更改发生的时间。

已验证的历史：历史记录中的每次更改都至少有一个经过强身份验证的参与者身份（作者、上传者、审阅者等）和时间戳。

无期限保留：工件及其更改历史无期限保留，无法删除。

两人审阅：历史上的每次变化，至少有两个可信赖的人同意。

【构建】工件构建过程的要求。

脚本化：所有构建步骤都在某种“构建脚本”中完全定义。唯一的手动命令（如果有的话）是调用构建脚本。

构建服务：所有构建步骤都使用某些构建服务，如持续集成（CI）平台，而不是开发人员的工作站。

临时环境：构建步骤在临时环境（如容器或虚拟机）中允许，仅为此构建配置，而不是从先前构建中重用。

隔离的：构建步骤在一个独立的环境中运行，不受其他构建实例的影响，无论是先前的还是并发的。构建缓存（如果使用）是纯内容寻址的，以防止篡改。

无参数的：构建输出不受除构建入口点和最高级别源码外的用户参数的影响。

不受外界影响的：所有的构建步骤、源和依赖项都使用不可变的、引用预先声明的，构建步骤在没有网络访问的情况下运行。所有依赖项都由构建服务控制平台获取并检查完整性。

可重现的：使用相同的输入，工件重新运行构建步骤，会导致逐位相同的输出。（无法满足此要求的构建必须提供理由）

【出处】工件出处要求。

可用的：出处可供工件的使用者或验证策略的任何人使用，它至少标识工件、执行构建的系统和最高级别的源码。所有工件引用都是不可变的，可以考虑借助加密散列。

已认证的：可以验证出处的真实性和完整性，可以考虑借助数字签名。

服务生成的：出处是由构建服务本身生成的，而不是服务之上运行的用户提供的工具。

不可伪造的：出处不能被构建服务的用户篡改。

依赖完整：出处记录了所有构建依赖项，即构建脚本可以使用的每个工件。这包括生成工作进程的计算机、虚拟机或容器的初始状态。

【通用】供应链（源码、构建、分发等）中涉及的每个可信系统的通用要求。

安全性：该系统符合一些TBD基线安全标准，以防止泄露（修补、漏洞扫描、用户隔离、传输安全、安全引导、机器标识等，可能是NIST 800-53或其子集）。

访问：所有物理和远程访问都必须是罕见的、有日志记录的，并在多方批准后关闭。

超级用户：只有少数平台管理员可以覆盖此处列出的保证。这样做必须需要第二个平台管理员的批准。

该框架来源于谷歌内部的“Borg二进制授权”，它已历经10年，是谷歌所有生产工作负载必须满足的框架要求，能够较全面地评估软件供应链完整性与安全性。企业可以借助SLSA框架，评估软件项目开发生命周期的完整性、透明度和安全性，确保风险可溯源、依赖关系透明、软件供应链的入口与输出都严格把控，做到供应链全程可审计、审批管控更加合规。

4.3.2.3 供应商安全检测实践方法

确定软件供应商安全检测评估方案后，需针对评估方案进行执行，执行方法包括针对评估目标采用检查、访问和测试等方法评估相应的文档、设备或活动，输出针对各项指标点的评估结果。

（1）访谈。企业通过与供应商相关人员进行有针对性的交流以帮助理解、厘清或取得证据，访谈的对象为个人或团体，如技术团队负责人、核心技术工程师、项目负责人等。

（2）检查。企业对供应商提供的相关凭证、资料、解决方案等进行查验，分析其真实性、权威性，并生成对应的技术设计文档、领域能力文档、检查记录等。

（3）测试。以供应商提供的方法、检测验证工具对供应商提供的解决方案进行场景预模拟测试，与预期结果进行比对，测试其应急响应能力、制度人员管理水平等。

4.3.3 软件产品安全评估

软件供应商的软件产品安全评估包含软件组成成分安全审查、软件漏洞风险评估、软件许可证风险评估、软件数据安全评估。在软件安全评估阶段，企业需要供应商按“最小要素”要求提供SBOM；在软件引入阶段，对产品资产进行全面的盘点和梳理，同时明确各潜在的风险点，若软件不符合安全基线要求则及时进行沟通与整改；同时，企业可以借助各类检测工具去验证供应商提供软件及其清单成分的真实性、完整性和安全性，如IAST、SCA、SAST、DAST等工具，能够对软件产品进行安全风险检测（见图4-6）。

4.3.3.1 软件物料清单

实现软件成分分析、风险评估和安全审查，始于对软件成分信息的完整、全面的把握，此时就需要引入软件物料清单的概念。软件物料清单（SBOM）的概念源于制造业，典型的SBOM是一份详细列出产品中所含全部项目的清单（见图4-7），这样一旦发现有缺陷的零部件，制造商便可以知道哪些产品受到了影响，并安排对其进行维修或更换。与制造业类似，软件物料清单是软件成分信息的集合，包括组成软件的所有组件的名称、组件详细信息、组件之间的关系如层级关系。每个软件都对应一张组成成分表，通过标准的数据格式存储、记录软件构成的基础信息，根据这些存储信息能够唯一地标识出这些软件中的组件。维护准确的、最新的、列出开源组件的SBOM对于确保代码的高质量、合规性和安全性是必要的。其能帮助用户快速查明风险，并合理确定补救措施的优先级。

Gartner在2020年发布的《应用程序安全测试魔力象限》中预测，2024年，至少一半的企业软件卖家要求软件供应商必须提供详细的、定期更新的软件物料清单，同时60%的企业将为他们创建的所有应用程序和服务自动构建软件物料清单，而这两组数据在2019年都还不到5%。

通过软件物料清单能够大大缓解软件供应链风险之一——溯源困难的问题。2020年12月13日，FireEye发布的关于SolarWinds供应链攻击事件就是典型的例子：因溯源困难，导致在安全事件发生时，无法快速溯源组件、定位风险点，没有及时采取有效的安全响应措施，造成大量数据泄露，包括机密资料、源代码及电子邮件等。美国政府、国防承包商、金融机构和其他许多组织都受到了影响，这些组织中还包括微软、思科和戴尔等知名公司。FireEye CEO Kevin Mandia表示：“我们投入了100名左右的人员，总共进行了10000小时的详细调查，我们依旧不知道攻击者的入侵路径。因此我们只好更进一步，反编译了18000个更新文件，3500个可执行文件，得到超过100万行的反编译代码，进行详细的代码审计，工作了1000小时以上，才得出结果，这就是为什么我们这么难以发现它。”由此可见，在软件引入阶段掌握清晰、详备的软件物料清单文件，能够帮助企业进行组件来源溯源与组件风险状态维护。同时，构建详细、准确的SBOM可以为漏洞风险治理节省大量时间（见图4-8），帮助所有利益相关者在漏洞披露早期立即开始评估漏洞，通过SBOM提供受感染开源组件和依赖项的准确位置，制定相关的补救措施，极大地降低后期安全运维成本。

落实构建SBOM，企业需首先根据实际情况，将软件“最小要素”分为不同粒度的“软件成分”，并引入软件供应链成分透明程度的概念，透明程度越高的软件，成分粒度越小（见表4-5）。

根据企业实际情况及需求确定软件成分“最小要素”，在不同透明程度下，构成一张软件成分信息集合的“软件成分清单”（见表4-6）。

部分软件检测工具能够提供自动化生成、管理SBOM的能力，通过自动化创建SBOM可以在漏洞披露时及时地进行响应、排查及快速的安全修复，最小化软件供应链的安全风险。企业可借助此类检测工具，如SCA，实现对供应商提供的软件物料清单的检测分析，帮助管理开源和第三方代码的使用，提升应用程序成分的可视度，标准化信息通信方式。除作为文档记录外，企业用户更应将SBOM视为一种管理系统或工具（见图4-9）。在开源组件版本快速迭代的情况下，借助SBOM，企业能够从风险管理的角度跟踪和持续检测闭源组件和开源组件的安全态势，溯源识别多层依赖开源组件，并将组件映射到漏洞数据。同时，SBOM列举了开源组件的许可证，管理许可证能够帮助企业规避因不合规的使用许可协议而带来的法律风险，保障应用程序在软件供应链中的合规性，避免将已知缺陷传递到软件供应链下游。企业应定时检测软件产品，保证软件物料文件清单的时效性。

4.3.3.2 软件成分安全审查

软件产品由多种不同的组件、库和工具构成，其中潜在的漏洞或许可协议问题，可能会导致数据泄露、系统崩溃、漏洞利用、法律侵权等风险。故若未在供应商软件产品引入前期，就对软件进行一系列周密的安全审查，可能会严重影响业务连续性、机密性和安全性。

对于软件成分的安全审查，包括上文中对于软件物料清单的审查与验证检测，还包括对软件产品中引用的开源项目、开源代码、开源组件、自研组件，组件间层级关系、依赖关系等进行统一的资产审查、风险检测与安全评估。软件组成成分审查能够保证软件产品数据安全，保护企业数据免受恶意攻击，帮助企业规避数据泄露的风险；同时能够确保软件产品满足合规要求，如金融行业需要遵守PCI DSS（支付卡行业数据安全标准）等标准；能够减少成本，软件成分审查能够帮助客户避免因软件漏洞和许可协议等问题带来的成本损失，有助于高效地进行版本控制和软件更新管理，减少运营成本。软件成分审查能够帮助客户与供应商建立信任关系。

4.3.3.3 软件漏洞风险评估

Gartner预测在2025年，全球45%的企业将经历软件供应链攻击，比2021年增加3倍。在数字战争的背景下，企业需做好充分的软件安全检测、维护和安全运维准备。在供应商软件产品引入前期，做好软件资产风险调研，全面掌握软件使用组件情况，考虑从许可证、组件使用年限、组件厂商、组件厂商所属国家、组件更新频率、组件漏洞风险等维度设立组件引入安全基线标准，对不符合标准的软件产品及时联系供应商进行修整更新。通过SBOM溯源组件信息并映射漏洞数据，掌握一份全面完整、真实有效的威胁渗透点清单。同时，考察软件供应商及其软件产品历史漏洞产出和修复情况，考察漏洞影响严重性及影响结果，软件供应商采取哪些措施减少漏洞出现、漏洞复现率、漏洞出现后的管理措施等；后期，可使用静态代码分析工具，对软件源代码进行安全审查、对已知漏洞和安全问题进行快速覆盖检测，持续监测管控漏洞，定期进行漏洞扫描、安全评估和补丁管理。

4.3.3.4 软件许可证风险评估

软件产品需要在遵循软件许可证规定的情况下进行分发。同时，软件许可证用于阐述最终用户义务。软件许可证的规定条款基本可以根据许可证类型分为两类：宽松许可证（Permissive License）和著作权许可证（Copyleft License）。宽松许可证基本不设任何使用条件，一般来说，此类许可证的主要要求是原始代码的归属权属于其原始开发者；著作权许可证通常涵盖互惠义务，规定代码的修改和扩展版本必须在与原始代码相同的条款和条件下发布，并且有改动的源代码必须按要求提供。商业实体对其软件中使用著作权许可证的开源代码十分谨慎，因为它的使用可能会带来整个代码库的知识产权（IP）问题，导致经济损失、软件下架、名誉受损，甚至源代码公开等风险。

Synopsys发布的《2023年开源安全和风险分析报告》中指出，在受审查的1703个代码库中，54%的代码库存在许可证冲突，31%的代码库包含没有许可证或使用定制许可证的开源代码（见图4-10）。企业特别是出口型企业，需在引入软件产品时审计软件产品携带的许可证资产，将许可证风险和冲突问题规避在软件引入阶段（见图4-11）。同时需注意，风险许可的引入可能源自开发人员手动将代码片段和部分组件添加到代码库中，或调用了开源项目社区中无许可证的项目代码，此时即需要专业的软件许可证识别分析工具与专业团队，去分析代码片段中携带的许可证信息。此外，标准开源许可证的变体或定制版本许可证可能会对被许可方提出不必要的要求，如JSON许可证便是定制许可证的典型示例，JSON许可证基于宽松许可证MIT，额外添加了“该款软件严禁用于恶意用途，仅限用于善意用途”的限制。该声明关于“善意用途”和“恶意用途”的界定含糊不清可能会为企业带来未知风险，因此许可律师都建议避免使用采用该许可模式的软件，尤其是在并购的情况下。

4.3.3.5 软件数据安全评估

软件产品的数据安全深刻影响着企业，包括软件数据本身、企业声誉、企业信用等多方面，对软件供应商提供的软件产品进行全方位的数据安全审查是非常重要的。近年来在国内外发生的数据安全事件屡见不鲜。

2021年3月，微软Exchange邮件服务器遭到黑客攻击。攻击者使用漏洞入侵系统并窃取了大量敏感信息。

2021年7月，Kaseya软件被黑客攻击，导致全球多个企业受到影响。攻击者使用该软件的漏洞进行攻击，并对许多企业进行了勒索软件攻击。

2021年8月，中国广州市电子证据研究所的“天网”监控系统泄露大量监控视频，该系统每天涉及4万多套监控摄像头，数据包括监控画面、位置信息等。

2022年10月，据中国香港媒体报道，香格里拉酒店集团的网络系统受到黑客攻击，其中3家位于中国香港，造成中国香港酒店29万份个人资料泄露。中国香港安全专家表示，通过技术分析，黑客可能通过传送电邮，在超链接中加入“钓鱼程式”，窃取酒店系统内的资料。

2022年11月，据中国台湾媒体报道，中国台湾地区相关系统遭黑客入侵，黑客在国外论坛公开出售2300万条中国台湾民众数据，打包价5000万美元。

2022年12月11日，蔚来汽车确认，因服务器配置错误导致百万条用户信息泄露，并遭受225万美元等额比特币的勒索。蔚来创始人、董事长、首席执行官李斌就数据泄露一事公开致歉。

屡次发生的数据安全事件已为企业敲响警钟，重视软件数据安全，保护用户隐私和敏感信息关系着企业自身与社会的健康发展。

企业可以采取以下措施、使用检测工具来检验软件供应商提供的软件产品的数据安全性：检测软件产品是否采用加密算法对高级别数据进行加密；对敏感数据是否设置身份验证和访问控制；软件系统是否记录潜在的安全漏洞或不当行为并追踪操作者；检测软件供应商是否具备数据备份机制，以便在发生数据丢失或系统故障时能够快速恢复数据；检测软件是否具备审计日志和事件监控能力，以便识别潜在的安全威胁和异常行为。 00XaggLoev1ScD1gtLxwf/9UV4V3FueMscqirSw00kcvvmsiVgDdAP0+Pn0l1rQz