OPSWAT的Secure SDLC 框架：对弹性和深度防御安全的承诺

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

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

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

OPSWAT 采用敏捷Software 生命周期。为了完全符合客户的要求，我们根据监管要求和国际标准采用了Secure SDLC 框架。这种方法强化了我们在不断变化的网络安全环境中持续改进和适应能力的承诺。

OPSWAT的Secure SDLC 框架建立在NIST SP 800-218SSDFSecure Software 开发框架）的基础上，确保在软件开发流程的各个阶段都能实现结构化、可衡量和一致的安全应用。  

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

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

随着网络安全法规的不断发展，OPSWAT 始终致力于使其Secure SDLC 框架与全球监管要求保持一致，首先是欧盟网络弹性法案和 NIS2 指令。通过主动适应新兴标准，OPSWAT 可确保其Secure SDLC 在日益复杂的监管环境中保持全面、合规和弹性。

维护稳健的信息安全对业务完整性和合规性至关重要。OPSWAT 的Secure SDLC 框架采用了 ISO 27001 ISMS（信息安全管理系统）原则，确保将安全控制、风险管理策略和合规措施无缝集成到我们的云产品操作中。 

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

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

为确保最高标准的软件质量，OPSWAT的Secure SDLC 框架已纳入 ISO 9001 QMS（质量管理体系）。该质量管理体系为治理、变更管理和跨职能流程建立了经过审核的质量控制，支持产品和支持服务的定义、设计、开发、生产和维护，并从研发扩展到销售、客户支持、信息技术和人力资源等领域。  

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

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

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

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

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

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

OPSWAT 的 "Secure SDLC 计划 "将Secure SDLC 框架转化为结构化管理，确保安全要求得到记录、维护、衡量和持续改进，同时还确保所有相关方接受适当的培训。它为开发、测试和生产环境以及管道安全确立了角色、责任和安全措施，定义了Secure 开发环境，并强制要求在Secure SDLC 流程中应用安全策略。

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

首席产品官 (CPO) 负责对所有产品团队的Secure SDLC 计划以及其他研发 (R&D) 计划（如质量保证 (QA) 计划和用户体验 (UX) 计划）进行战略监督和实施，确保以协调一致的方式进行安全、高质量和以用户为中心的软件开发。

作为所有产品和研发流程的主要风险负责人，首席采购干事授权研发运营部负责Secure SDLC 计划，并确保产品负责人执行Secure SDLC 计划，在产品团队中有效实施Secure SDLC 流程。首席采购干事负责批准Secure SDLC 计划的修改和偏离Secure SDLC 流程的情况。

首席采购干事还负责监控Secure SDLC 计划的成果，跟踪安全成熟度、漏洞、合规性和开发活动，以保持产品的稳固安全态势。

此外，CPO 还负责研发安全预算的分配和审批，确保为Secure SDLC 计划提供充足的专用资源。

战略重点

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

作为Secure SDLC 计划的一部分，除了公司的一般安全意识培训外，还强制要求所有参与安全开发的员工接受特定角色的安全培训。公司的培训工具会对所有培训进行跟踪。培训和意识计划会定期审查，以纳入新的安全趋势，确保持续符合安全标准。

OPSWAT 致力于通过结构化的绩效衡量、成熟度评估和定期更新，不断加强其Secure SDLC 计划，以确保持续的安全有效性。  

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

为有效衡量应用程序安全状况，OPSWAT 使用结构化指标对团队进行评估。根据 SAMM 框架对每个团队的产品安全成熟度进行评估，为安全进展提供可量化的衡量标准。此外，产品还要接受 ASVS 合规性评估，以确保符合安全验证要求。Secure SDLC 流程的合规性受到密切监控和评估，KPI 目标的实现以证据为基础，确保安全态势和安全改进是可衡量和可操作的。作为年度绩效评估的一部分，所有产品团队都必须达到安全成熟度目标。 

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

为进一步加强安全管理，OPSWAT 对Secure SDLC 框架进行了年度审查，纳入了对过去安全事件的根本原因分析、漏洞趋势评估以及对现有流程和政策的改进所得出的见解。  

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

Secure SDLC 流程通过定义团队必须遵循的安全控制，包括每个开发阶段的自动安全检查和验证机制等具体活动，进一步落实了Secure SDLC 计划。该流程与其他关键研发计划（如质量保证计划和用户体验计划）保持一致，确保以协调一致的方式进行安全、高质量和以客户为中心的软件开发。 

Secure SDLC 流程详见以下章节：

• Secure 设计和风险评估
• Secure 实施、构建和部署
• 应用程序安全测试与验证
• Secure 发布
• Secure 运行和维护

Secure SDLC 流程是一个高层次的流程，团队可以以扩展定制的方式实施该流程，但条件是流程的安全性必须保持在最低水平。偏离Secure SDLC 流程的行为必须记录在案并获得批准。

Secure SDLC 计划包括各种政策，产品团队必须正式批准和确认这些政策，以确保符合其要求。内部必须遵守这些政策，每个团队都有责任审查、签署和实施这些政策，并将其作为开发流程的一部分。 

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

作为Secure SDLC 流程的一部分，在整个开发生命周期中都要跟踪、记录和维护安全要求。第三方供应商必须承认并满足 ASVS，确保所有软件组件的安全预期和遵守产品隐私合规政策的一致性。 

安全已融入开发生命周期的每个阶段。安全拥护者有责任牢记Secure SDLC 流程的期望，并在其团队中代表这些期望。 

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

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

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

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

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

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

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

作为Secure SDLC 流程（包括实施、构建和部署）的一部分，其目的是在Secure 设计和风险评估的基础上防止漏洞和缺陷。要求集包含对基于 ASVS 的功能性和非功能性安全要求、安全开发和测试方法的期望，这些都依赖于Secure 开发环境。  

在实施过程中，必须采用Secure 编码最佳实践、Secure 代码审查和Secure 早期检测。团队必须遵守Supply Chain 安全政策（包括供应商入职和开源软件主题）、人工智能使用政策和恶意软件样本处理政策。在构建和部署过程中，必须使用集中式 CI/CD 管道和职责分工进行Secure 构建和部署。

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

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

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

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

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

作为应用程序安全验证政策所要求的安全审查的一部分，安全代码审查非常重要，并根据开发技术的不同而执行，根据OWASP Cheatsheet系列应用各种Secure 代码审查清单。

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

作为Secure SDLC 流程的一部分，必须使用集中、协调的 CI/CD 管道来执行安全构建并避免供应链攻击。审计、构建和部署日志会按照公司安全策略的规定进行生成、保存和审查。 

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

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

根据我们的应用程序安全验证政策，我们对发现的问题进行正式记录和跟踪，并为持续验证分配自动化工具。作为Secure SDLC 流程的一部分，我们在 SDLC 的每个阶段都实施并跟踪安全检查，以满足合规要求。其目的是有效查找可能存在的安全漏洞。团队会对出现的安全问题进行调查，并在规定时间内解决。时间框架是已定义的安全关键绩效指标的一部分。

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

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

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

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

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

作为Secure SDLC 流程的一部分，发布流程根据应用程序安全测试和验证的结果，执行发布标准，以确保遵守Secure SDLC 流程和产品的整体安全性。作为每个版本的基本要求，产品版本在维护各版本的安全改进、防止与安全相关的倒退以及维护已实现的安全态势方面发挥着至关重要的作用。 

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

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

根据 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 SDLC 流程的范畴。

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

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

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

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

违反Secure SDLC 的上报流程：任何违反本政策的行为都将在内部处理，从研发运营部开始，必要时升级到首席产品官 (CPO)。

为 ISO 27001、SOC2 和 NIST SSDF 范围内的产品提供组件或服务的供应商应遵守以下Secure SDLC 框架的要求。合规与否取决于定期安全审计、第三方评估以及双方在已执行合同中的义务。 

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

产品组件和程序库供应商必须按照Secure 开发环境部分所述，建立与我们的实践相一致的开发环境。产品组件和程序库供应商必须对其组件和程序库进行安全测试，详见 "应用程序安全测试与验证 "部分。 

管道组件供应商还必须建立与Secure 开发环境部分所述的我们的实践相一致的开发环境。此外，他们的开发流程必须符合OPSWAT的Secure SDLC 流程。 

服务供应商应使用基于美国的环境，提供与OPSWAT服务相当的安全态势。他们的Secure SDLC 必须包括Secure SDLC 计划和Secure SDLC 流程，以反映OPSWAT的期望。