OPSWAT Secure 框架：对韧性与深度防御安全的承诺

恶意行为者以系统牟利或破坏为目标，给组织带来成本、业务风险和声誉损失。 

根据最近的一项调查，与分析和需求阶段相比，在生产阶段发现安全漏洞的修复成本要高出 30 倍。

OPSWAT Secure 框架”定义了指导安全软件开发的结构化方法论和安全原则。 

OPSWAT 敏捷Software 生命周期（Agile SDLC）。为了全面满足客户的要求，我们根据监管要求和国际标准采用了Secure 生命周期框架”（Secure Framework）。这一做法彰显了我们在不断演变的网络安全环境中对持续改进和韧性的承诺。

OPSWAT Secure 框架”基于NIST SP 800-218SSDF（Secure Software ）构建，确保在软件开发过程的所有阶段，安全性都具有结构化、可衡量且能得到一致应用。  

通过整合 SSDF 最佳实践，OPSWAT 保持了积极主动的安全态势，将安全嵌入软件开发的每个阶段--从规划和设计到实施、验证和持续监控。 

我们按需向美国联邦政府客户提供单个产品的合规性证明。请参阅以下联系方式。

随着网络安全法规的不断演变OPSWAT 致力于使其Secure ）框架”与全球监管要求保持一致，首先从《欧盟网络弹性法案》和《NIS2 指令》入手。通过主动适应新兴标准OPSWAT 其Secure ”框架在日益复杂的监管环境中保持全面、合规且具有韧性。

维护强有力的信息安全对于运营完整性和合规性都至关重要。OPSWAT Secure 框架”融入了 ISO 27001 信息安全管理体系（ISMS）的原则，确保安全控制措施、风险管理策略和合规措施能够无缝融入我们云产品的运营之中。 

作为我们安全解决方案的提供者和消费者，OPSWAT 采用公司内部执行的安全政策，确保我们的认证产品在部署前符合企业级安全要求。  

查看合规性与认证的更多详情。

为确保软件质量达到最高标准OPSWAT Secure 框架”已整合到 ISO 9001 质量管理体系（QMS）中。该质量管理体系针对治理、变更管理及跨职能流程建立了经过审计的质量控制措施，支持产品及支持服务的定义、设计、开发、生产和维护，其覆盖范围不仅限于研发，还延伸至销售、客户支持、信息技术和人力资源等领域。  

这种方法强化了我们对结构化、基于风险的质量管理方法的承诺，确保应用安全始终是所有业务职能部门不可或缺的考虑因素。

查看合规性与认证的更多详情。

OWASPSoftware 保障成熟度模型 (SAMM)是一个综合框架，旨在帮助企业在现有的 SDLC 中评估、制定和实施有效的软件安全策略。

作为一个开源框架，SAMM 受益于全球的贡献，确保了应用安全的协作性和持续发展性。其结构化方法使企业能够以有效、可衡量的方式分析和改进其开发生命周期。SAMM 支持整个开发生命周期。SAMM 与技术和流程无关。SAMM 具有进化性和风险驱动性。通过利用 SAMM，团队可以深入了解安全漏洞，并在整个开发生命周期内系统地增强安全态势。

OWASP 应用程序安全验证标准 (ASVS)是一个全球公认的框架，旨在为网络应用程序的安全建立一个结构化、可衡量和可操作的方法。它为开发人员和安全团队提供了一套全面的安全要求和验证指南，以确保应用程序符合行业最佳实践。 

作为一个开放源码框架，ASVS 得益于全球安全社区的广泛贡献，确保其与新出现的威胁和不断发展的安全标准保持同步。

OPSWAT Secure Secure Secure Secure Secure ”计划Secure 框架”转化为结构化的治理机制，确保安全要求得到记录、维护、评估和持续改进，同时确保所有相关方均接受充分的培训。该计划明确了开发、测试和生产环境中的角色、职责及安全措施，涵盖了开发流程的安全性，定义了Secure 环境”，并强制要求在Secure ”流程中贯彻执行安全策略。

高层管理人员 - 首席产品官 (CPO)

首席产品官（CPO）负责对所有产品团队的Secure 计划”以及其他研发（R&D）计划（如质量保证（QA）计划和用户体验（UX）计划）进行战略监督和落实，确保在软件开发过程中采取一致的方法，以实现安全、高质量且以用户为中心的软件开发。

作为所有产品和研发流程的主要风险负责人，首席产品官（CPO）要求研发运营部门负责Secure （Secure Secure ）计划”，并确保产品负责人在产品团队中有效落实Secure 计划并实施Secure 流程。在此职责范围内，首席产品官（CPO）负责审批Secure ”计划的修改，以及对Secure ”流程的偏离。

首席产品官（CPO）还会监督Secure 计划”的实施效果，跟踪安全成熟度、漏洞、合规性及开发活动，以确保产品保持强大的安全态势。

此外，首席采购官（CPO）还负责研发安全预算的分配和审批，以确保为Secure 计划”配备充足的资源。

战略重点

OPSWAT的应用程序安全战略计划与其业务优先事项和风险偏好保持一致，同时考虑到每个产品的成熟度及其面临的安全威胁。主要重点是保护高风险产品，特别是那些拥有庞大客户群、面向公众部署或集成到关键基础设施中的产品。

作为Secure 计划”的一部分，除公司常规的安全意识培训外，还要求所有参与安全开发的工作人员必须接受针对其具体岗位的安全培训。所有培训情况均通过公司的培训工具进行记录。公司会定期审查培训和安全意识项目，以纳入最新的安全趋势，并确保持续符合安全标准。

OPSWAT 通过结构化的绩效衡量、成熟度评估以及定期更新，持续改进其Secure 计划”，以确保安全措施的持续有效性。  

为了保持强大的安全态势，OPSWAT 采用了系统的方法来跟踪和改进安全性能。这包括每季度进行一次产品安全成熟度评估，进行内部安全审查以核实是否符合最佳实践，以及定义年度关键绩效指标（KPI），并每季度对其进行衡量。  

为了有效衡量应用程序的安全状况OPSWAT 采用结构化指标OPSWAT 团队OPSWAT 。根据 SAMM 框架，对每个团队的产品安全成熟度进行评估，从而提供可量化的安全进展指标。此外，产品还会接受 ASVS 合规性评估，以确保符合安全验证要求。Secure 流程”的合规性进行密切监控和评估，关键绩效指标（KPI）目标的达成情况以证据为依据，从而确保安全状况和安全改进既可衡量又可付诸行动。 所有产品团队都必须达到安全成熟度目标，这是其年度绩效评估的一部分。 

作为持续改进工作的一部分，OPSWAT 定期推出新的产品安全计划，以提高成熟度并加强应用安全。这些措施包括更新安全政策以应对新出现的威胁，整合新的安全工具以加强检测和预防，以及扩大关键绩效指标目标以推动持续进展。 

为了进一步加强安全治理OPSWAT 每年OPSWAT 对Secure ”框架OPSWAT 了对以往安全事件根本原因分析的见解、对漏洞趋势的评估，以及对现有流程和政策的优化。  

这种持续改进的结构化方法可确保OPSWAT 保持积极主动和弹性的产品安全态势，有效地适应不断变化的网络安全挑战，同时满足监管和运营安全目标。

Secure Secure Secure 流程”通过定义团队必须遵循的安全控制措施，进一步推动Secure 计划”的落地实施，其中包括在每个开发阶段开展的具体活动，例如自动化安全检查和验证机制。该流程与其他关键研发计划（如质量保证计划和用户体验计划）保持一致，确保在软件开发过程中采取统一的方法，以实现安全、高质量且以客户为中心的软件开发。 

以下各节详细介绍了Secure 开发生命周期（Secure ）流程：

• Secure 与风险评估
• Secure 、构建和部署
• 应用程序安全测试与验证
• Secure
• Secure 与维护

Secure 流程”是一个高层次的流程，各团队可在满足流程安全性至少保持在最低要求水平的前提下，以扩展和定制的方式实施该流程。任何偏离Secure ）流程”的情况均须记录在案并获得批准。

Secure 计划”包含多项政策，产品团队必须正式批准并确认这些政策，以确保符合其要求。内部必须严格遵守这些政策，每个团队都有责任将其纳入开发流程，并负责审查、签署和实施这些政策。 

以下是主要政策及其各自的目的。对于具有外部意义的政策，本文件将纳入更多细节。

Secure （Secure ”流程的一部分，在整个开发生命周期中，安全要求都会得到跟踪、记录和维护。第三方供应商必须认可并符合 ASVS 标准，以确保所有软件组件在安全要求方面保持一致，并遵守《产品隐私合规政策》。 

安全性已融入开发生命周期的每个阶段。安全负责人有责任牢记Secure 生命周期（Secure ）流程”的预期要求，并在各自团队中贯彻这些要求。 

Secure 需求集包括基于ASVS的功能性和非功能性安全需求。研发运营部门提供了参考模型以支持设计决策，并在必要时对ASVS需求进行记录在案的调整（例如，更严格的加密要求）。

威胁建模是一种结构化的流程，旨在在开发生命周期的最早阶段识别威胁和漏洞。它是Secure （Secure ”流程不可或缺的一部分，应定期进行——至少每年一次，或在引入新功能或架构变更时进行。产品团队通过定义安全目标、识别资产和依赖关系、分析潜在攻击场景以及缓解已识别的威胁来实施威胁建模。  

增强型方法结合了数据流分析和成熟的威胁建模实践（如 STRIDE 模型），确保对所有产品进行全面评估。必要时，会启动安全审查，以验证是否符合安全要求，并积极应对潜在风险。设计决策会被仔细记录下来，并在整个产品生命周期内持续跟踪任何遗留风险。

应用程序安全风险通过多种来源进行评估，包括威胁建模过程中发现的残余威胁、公认的安全漏洞（如 OWASP Top 10 和 SANS Top 25 中的漏洞），以及基于 ASVS 指南的安全控制缺失。其他风险因素包括整个构建、部署和发布流程中的秘密管理薄弱环节，以及开源和第三方组件中的漏洞。 

在风险评估之后，将制定减轻风险计划，以降低已确定风险的严重性，同时考虑到影响和可能性。这些计划以及相应的风险和缓解步骤都会被完整地记录下来。 

残余风险在整个产品生命周期内都会被跟踪，并接受定期审查，而且必须得到风险所有者的正式确认。这些风险还被纳入内部发布报告，以保持可见性和责任性。 

必要时，会启动安全审查，以确保符合安全要求，并主动应对潜在风险，加强产品的整体安全态势。

作为Secure 流程的一部分，包括实施、构建和部署，旨在基于Secure 和风险评估来防范漏洞和缺陷。该需求集包含对基于ASVS的功能性和非功能性安全要求，以及依托Secure 环境的安全开发和测试方法论的预期。  

在实施过程中，应应用Secure 最佳实践、Secure 审查以及安全漏洞的早期检测。各团队必须遵守《Supply Chain 政策》（包括供应商入驻和开源软件相关内容）、《人工智能使用政策》以及《恶意软件样本处理政策》。在构建和部署过程中，必须Secure 和部署方式，使用集中式的 CI/CD 管道，并落实职责分离原则。

在实施过程中，产品团队必须遵循与语言无关的安全编码最佳实践。他们必须验证输入数据、对发送到其他系统的数据进行消毒、消除编译器警告、设置安全错误信息、在适用情况下应用输出编码、在不暴露敏感数据的情况下实施安全日志记录，并遵循正确的错误处理和异常管理准则。团队还必须确保加密技术（如果使用）依赖于经批准的算法和安全的随机数生成，并通过安全地处理内存、防止竞赛条件和通过适当的同步避免死锁来安全地管理系统资源。 

此外，还建议产品团队遵循由 SAST 工具执行的特定语言安全编码指南，如下所示： 

对于Java，团队应确保比较操作中使用的密钥不可变，使用 SecureRandom 而不是 Random，并通过验证或限制输入类来避免不安全的反序列化。

在C++ 中，建议检测和处理内存分配错误，通过边界检查和使用智能指针（如 std::unique_ptr()）来防止缓冲区溢出，并避免使用不安全的函数（如 strcpy() 和 sprintf()）。 

对于Python，开发人员应避免使用 eval() 或 exec() 等函数，以降低代码注入风险，并在处理不受信任的数据时，优先使用 json 模块等安全序列化格式，而不是 pickle。

作为《应用程序安全验证政策》所要求的安 全审查的一部分，安全代码审查至关重要，其实施需根据开发技术而定，并依据OWASP速查表系列应用Secure 审查检查表。

根据应用程序安全验证政策的要求，及早发现安全漏洞是开发流程的关键组成部分。为了最大限度地减少潜在的安全问题，必须采用 "无法构建 "的方法，确保不安全的代码不会通过管道。此外，还强制执行 "合并失败 "方法，要求团队在整合变更之前修复任何检测到的问题。解决检测到的缺陷对于达到发布标准至关重要。

作为Secure 流程的一部分，必须使用集中化、协调一致的持续集成/持续交付（CI/CD）管道，以确保构建安全并防范供应链攻击。审计、构建和部署日志将按照公司安全政策的规定进行生成、保存和审查。 

每个产品团队都有责任在适用情况下遵循安全的构建和编译器配置。他们必须使用安全编译器选项、禁用调试代码、加固解释型语言的运行时、固定依赖版本、确保可重复构建，并加固容器映像。所使用的配置必须记录在案并定期审查。 

根据职责分离原则，开发人员和其他拥有代码或构建权限的团队成员不能访问生产环境。对于云产品，只有产品的现场可靠性工程师才能部署到生产环境中。

根据我们的《应用程序安全验证政策》，我们会对发现的问题进行正式记录和跟踪，并部署自动化工具进行持续验证。Secure ”流程的一部分，在软件开发生命周期的每个阶段都会执行并跟踪安全检查，以满足合规要求。这些措施旨在高效地发现潜在的安全漏洞。出现的安 全问题将由相关团队进行调查，并在规定时限内予以解决。这些时限是既定安全关键绩效指标（KPI）的一部分。

• 架构和设计审查：高级工程师和应用安全虚拟团队成员对设计变更中的安全方面进行评估，包括加密、验证、授权、审计、系统加固、系统和网络架构。 
• 代码审查： 在同行和高级工程师定期审查代码的基础上，应用程序安全虚拟团队的成员还会审查更改，以防止常见缺陷，如注入、错误处理和不安全配置。

• 秘密扫描，避免秘密外泄，确保秘密处理的良好设计和安全实施。
• 用于检测漏洞（如 SQL 注入、缓冲区溢出）的SAST（静态应用程序安全测试）工具。
• SCA（Software 构成分析）用于检测开源漏洞。
• DAST（动态应用程序安全测试）用于发现运行时（如内存缺陷）和环境问题

在 CI/CD 管道中必须使用 "安全问题的早期检测 "部分中定义的工具。所有发现的漏洞都必须按照产品Vulnerability Management 进行修复。

自动和手动安全测试方法的使用与执行安全测试计划的质量保证计划相一致。

• DAST 工具 用于检测运行时的漏洞、测试默认配置，以及测试应用加固建议后的系统恢复能力。这些测试同时针对软件和底层基础设施。 
• 为避免安全要求和功能出现倒退，我们使用自动测试工具不断验证安全功能和控制措施的完整性。 
• 人工测试 适用于自动化工具不足的地方，如验证信息泄漏控制、识别业务逻辑缺陷和上下文漏洞。 
• 对开发生命周期中的工件进行自动恶意软件扫描，也是预防安全问题步骤的一部分。

Secure 的一部分，发布流程会根据应用程序安全测试和验证的结果，强制执行发布标准，以确保既符合Secure 流程”的要求，又能保障产品的整体安全性。产品版本管理在保持各版本间的安全改进、防止安全相关的回归问题以及维持已实现的安全状态方面发挥着至关重要的作用，这是每次发布的基本要求。 

发布流程包括生成内部发布报告，记录残余风险和任何悬而未决的安全问题。这些报告必须由产品负责人正式批准。此外，作为产品正式发布的一部分，外部发布说明会传达与安全相关的更改和修复。 

对于云产品，部署遵循 "部署失败 "自动化方法，确保只发布安全的构建。应用安全测试和验证被集成到部署管道中，采用操作拉动策略而不是推送策略，在生产部署前加强安全验证。 

根据 SBOM 管理政策，每个版本都包含一个Software Bill of Materials (SBOM) ，以保持组件来源的可追溯性，支持透明度和供应链安全。所有必要的发布文件都被安全存档，以确保长期可访问性。

根据 "发布完整性政策"，为维护产品发布的完整性和安全性，我们采用了结构化版本系统（如语义版本系统），以确保变更的清晰可追溯性，并为包括文档在内的所有发布成果规定了明确的保留期限。为进一步提高安全性，软件产品均以公司名义进行数字签名，并公布 SHA 指纹，以便用户验证真实性并检测任何篡改企图。 

每个版本都附有版本化文档 ，提供有关完整性验证方法、安全安装程序、配置最佳实践和系统加固措施的详细指导。这些资源可帮助用户有效实施安全控制，减少潜在的攻击面。此外，还包括最终用户许可协议（EULA），以确定合规义务并保持法律透明度。 

个别产品的 SBOM 可按需提供给我们的客户。请联系我们。

开发、测试和生产环境被安全地分开，以防止未经授权的访问。每个环境都遵循严格的加固基线和端点安全协议。开发环境必须符合公司的安全政策。

作为端点保护的一部分，对OPSWAT 拥有的所有设备进行监控，以发现漏洞、安装的软件、安装的补丁以及是否符合公司安全政策。如果出现违规情况，将采取限制措施，限制对公司资源的访问。 

被列为高风险类别的资源只能通过受控访问路径（VPN）访问。公司网络之外的设备必须使用安全通道访问研发资源。

CI/CD 管道安全遵循严格的安全指令，以减轻不断变化的威胁。威胁的源头可能是过时的基础架构元素（如操作系统、分析工具等）、因权限控制薄弱而导致的未经授权的访问以及隔离不佳的环境。保持 CI/CD 基础架构的及时更新、彻底审查和严格控制是我们安全 SDLC 的基石。 

从地区上看，所有集中式服务都使用美国服务器，包括代码存储、CI/CD 管道、分析和测试工具以及安全工件签名。所有集中式工具的配置均由研发运营部控制。 

我们采用强大的身份验证机制（多因素身份验证 - MFA）和授权控制（基于角色的访问控制 - RBAC）。我们实行最低权限和定期访问审查。 

我们的管道集成了多种分析和测试自动化工具，包括静态应用安全测试 (SAST)、Software 构成分析 (SCA)、动态应用安全测试 (DAST)、秘密扫描和恶意软件扫描。 

在我们的安全代码签名解决方案中，我们使用Hardware 模块（HSM）来保护密钥材料，防止未经授权的访问，并生成签名。签名解决方案是 CI/CD 基础设施的一部分，但网络分隔已经到位。只有研发运营部门有权短时间访问 HSM。每个签名操作都会被记录下来，并可在审计跟踪中进行审查。 

用于构建、编译或测试软件的工具集必须具备溯源信息，并来自经过验证的来源。CI/CD 管道中使用的工具数量有限；仅安装必要的工具。管道中的编译和构建步骤仅允许使用 LTS 软件。在集中式服务的运行过程中，已明确规定定期维护和密钥轮换周期。内部开发的工具须遵循Secure ”流程。

所有集中式服务的环境加固都是持续性的，并定期审查这些安全要求。加固指南会传达给产品团队，以确保他们做好准备，并可相应调整其开发流程。一旦发生安全事故，将进行 RCA 以采取预防措施并更新这些要求。

保护源代码是软件开发的关键部分，以确保公司内部源代码的保密性和完整性。 

源代码的存储遵循最小权限原则，只允许经授权的人员和工具访问。源代码受版本控制。版本控制管理系统确保代码更改的可追溯性和责任性。源代码存储采用符合 FIPS 140-3 标准的加密技术，并以适当的密钥长度进行保护。

所有内部团队都必须遵守本政策。本文件从属于公司政策，也就是说，如果出现任何矛盾，则以公司政策为准，必须遵照执行。 

Secure ）违规的上报流程：任何违反本政策的行为均由内部处理，首先由研发运营部门负责，必要时上报至首席产品官（CPO）。

为ISO 27001、SOC2、NIST SSDF适用范围内的产品提供组件或服务的供应商，应遵守《Secure 框架》（Secure Framework）中概述的以下要求。合规情况将接受定期安全审计、第三方评估，并受已签署合同中各方的义务约束。 

所有供应商都必须按照 "发布完整性 "部分的规定，提供出处和完整性信息以及证明文件。 

产品组件和库供应商必须建立符合Secure 环境”一节所述实践的开发环境。他们必须按照“应用程序安全测试与验证”一节所述，对其组件和库进行安全测试。 

管道组件供应商还必须建立符合Secure ”一节中所述我们实践要求的开发环境。此外，其开发流程必须符合OPSWAT Secure 流程。 

服务供应商应使用位于美国境内的环境，其安全水平应OPSWAT的服务相当。其Secure ）必须同时包含OPSWAT要求的Secure 计划”和Secure 流程”。