传统上, software providers have implemented Software Development Lifecycle (SDLC) management procedures to ensure a structured and consistent approach to software development practices, 确保SDLC过程的所有阶段(计划), 设计, 构建, 释放, 维护, 支持和退役)将以受控的方式执行. 而这些程序的实施，达到了高质量的功能性产品, 它们不一定能解决安全问题.
“保护产品”的步骤通常是SDLC过程的附加内容, 在很多组织中, 安全性被视为“最好有”的检查或产品验证过程中的最后一步. 尽管如此，这种对安全的不重视不会长久. 安全性通过设计实践和产品内置的安全特性正在成为, 更频繁地, 软件产品的大型澳门赌场官方下载客户的不可协商的需求. This is due to the upsurge of third-party software 漏洞 and the high impact of the materialized supply chain attacks experienced during the past few years (e.g.、SolarWinds、Log4j、3CX、MOVEit).
结果是, 澳门赌场官方下载客户, 尤其是那些购买力和议价能力强的人, 不只是对新事物感兴趣吗, 革命性的软件产品，但也在安全, 安全使用的产品. 软件制造商和供应商, 这意味着安全不再是一种选择，而是“必须拥有”,当你有疑问的时候, we should ask ourselves a very simple question: If our customers entrust us their most important asset (data), 难道我们不应该提供同等级别的安全保障吗, 我们提供给他们的软件产品的可靠性和透明度?
开发具有设计安全性的优秀软件
但是实现安全软件开发生命周期(SSDLC)过程并不是那么简单. The first step is to ask our organization if we are ready to have such process in place; to not just develop great software but do it with security-by-设计 principles in mind. 领导层对安全的承诺在这里变得至关重要. 当有来自高层的参与时, 安全不再是“有就好”的概念，而是一种管理声明, 公司原则, 共享的团队价值, 有形的目标, 细化和规划期间的优先级, 跨SDLC的一组强制性步骤和检查, 管理报告中的KPI/KRI, 等等....... 当这种情况发生时, 安全不再是单独的“待办事项”,” but it´s embedded in the DNA of our teams and we start delivering products in line with the commitments we have made, 从证明到证明我们的健壮性, 可靠性, 可持续性和透明度.
2022年2月， NIST发布了安全软件开发框架(SSDF)版本1.1，描述了在SDLC过程的所有阶段中嵌入安全性的建议. 在这个框架中，NIST提出了四组实践:
- 组织准备(PO):组织应该确保他们的人员, 过程和技术准备在组织级别执行安全的软件开发.
- Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access.
- Produce Well-Secured Software (PW): Organizations should produce well-secured software with minimal 安全漏洞 in its 释放s.
- Respond to Vulnerabilities (RV): Organizations should identify residual 漏洞 in their software 释放s and respond appropriately.
All four groups of practices provide high-level principles and underlying notional examples to satisfy the criteria of what a secure software product should be. 在每一个实践中, NIST also touches on how we should manage the security risks introduced by third-party software components (approximately 20% of the entire framework).
第三方组件的使用, 无论是销售软件还是开源软件(OSS), continues to grow as the software development community sees that component-oriented development saves time and enhances the quality of the custom software. 研究表明，76%的代码库都是如此 通常是OSS代码，这意味着OSS在我们的软件组合中的权重是相当显著的. 但是开源软件和第三方组件, 在一般情况下, 继续被忽视, 或者我们只是继续假设，如果它们被广泛分发和使用, 它们必须安全使用. 因此，当涉及到第三方组件风险时，存在一种错误的安全感. ISACA 2022供应链安全研究报告 调查显示，受访公司:
- 近五分之一的第三方评估不包括网络安全和隐私评估.
- 39%的澳门赌场官方下载没有与供应商制定针对网络安全事件的事件响应计划.
- 49%的受访者表示，他们没有对供应链进行漏洞扫描和渗透测试.
- 61% say their risk assessments do not include supply chain risk assessments specifically for devices using artificial intelligence (AI).
然而, 因为最近的软件供应链攻击, companies are trying to get more visibility into their supply chain 依赖关系 and understand the risks these introduce to their environment. 在下一节中, 我想对NIST框架进行扩展，并阐明软件制造商的实践, 供应商 和客户 can apply to manage third-party components risks effectively as part of the SSDLC process:
- 在引入第三方组件之前进行目的、可行性和可维护性研究: 就像寻找工具供应商或专业服务一样, 不应低估第三方软件组件采购过程的重要性. 因为这个原因, 制定一些基本规则来选择和执行适当的组件是很重要的:
- Define Purpose: Evaluate multiple components to determine 哪一个 one best satisfies the functionality that is required. 记录至少三个首选组件的优缺点.
- 确定可行性:评估开发您自己的功能的成本与. 利用第三方组件，包括短期的和长期的. 评估集成工作的可行性和成本，以及维护这些工作所需的资源.
- 分析可维护性:经常被忽视, 由于时间紧迫，无法在短期内交付产品, 组件的可维护性应该是决定是否使用它的决定性因素. 要解决的简单问题包括:关于组件是否有足够的文档和支持? 是否有产品路线图? 组件是否定期更新? 我们能跟上所有的更新吗? 我们能够防止遗留组件吗?
- 第三方软件组件也应该进行第三方风险评估:
Business Impact Assessments (BIA) and Third-Party Risk Assessments (TPRA) have been widely adopted as the preferred methodology to understand vendor risks and reject or accept 供应商 depending on whether they fit within our risk appetite posture. Vendors of tools and 服务 are most commonly subject to these exercises while third-party components of our own software products are often exempted. 无论是电子邮件发送的应用程序，翻译的解决方案，还是 AI-driven聊天机器人, all application-like components should be assessed against the security and privacy-related criteria for selecting 供应商. 这些标准可以包括我们的加密需求, 第三方补丁管理和漏洞披露程序, 产品安全事件响应能力, 审核SOC 2报告, ISO 27001适用性声明(soa), 以及数据保护政策审查, 在组织认为重要的其他关键因素中. A TPRA that results in risks or findings should be used to decide whether to approve the use a component and to periodically review and follow up upon it.
- 利用软件组合分析(SCA)和SBOM加强安全性:
就像我们对我们消费的食品的成分感兴趣一样, having an interest in the ingredients that make up our software products can give us meaningful information about the security, 它们的遵从性和可维护性. Leveraging automated solutions such as Software Composition Analysis (SCA) to analyze SBOMs (Software Bill of Materials) can be a good start to being more in control of our software products and to proactively manage supply chain risks. 取决于格式, 是否是SPDX, CycloneDX或SWID, soms可以为我们提供产品组件的数据来源, 例如制造商名称, 包版本, 授权信息, 漏洞, 包的关系, 服务, 依赖关系, 还有更多. 这样的来源信息可以帮助我们识别许可证冲突和遵从性问题, 安全漏洞, VEX(漏洞利用交换), 文件的完整性, 并潜在地识别“高风险”成分, e.g. 废弃软件(两年或两年以上未更新), 空包(没有源文件), 本机二进制代码(通常与包的类型无关的可执行代码), 可以用作攻击向量). 作为这种分析的结果, 我们可以决定哪些组件必须被批准(黑名单)，哪些组件被批准(白名单)。.
The use of SBOM in our third-party risk management procedures and as an underlying element of the SSDLC Process drives the transparency between the developer community, 软件制造商, 供应商, 和客户. 这让我们在防范零日威胁和供应链攻击方面领先一步, 同时帮助我们交付质量更好的可持续软件.
其他重要考虑事项
在保护我们的产品免受供应链攻击的过程中, the implementation of SSDLC policies and Third-Party Risk Management procedures alone will not suffice without the formal appointment of Product Owners (POs). 所有权是位于聚合产品级别还是基于组件级别, it is essential that someone within the organization takes ownership for the secured end-to-end lifecycle management of the product and its components.
除了, 所有产品和基础组件的最新库存, 具有指定的风险分类(例如.g.(高、中、低风险)，应予以维持. 盘点我们拥有的东西, 尤其是我们赞成或不赞成的东西, 对我们的产品风险前景的可见性是必要的吗, 其复杂性, 如果出了什么问题，对业务的影响.
最后，正如俗话所说，“信任，但要核实。.” A process can never be labeled as effective if we don’t perform an independent review to verify it works as expected and that risks are identified and controlled. 至少, high-risk products should be audited against the expected secured development lifecycle practices and attention should be given to their third-party composition and 依赖关系.
了解表面之下的东西
学会把安全作为设计的关键要素, 构建和实现我们的软件产品是一个需要意识和承诺的过程, but understanding the impact that third-party components play in achieving the desired level of product security is one step further that not everyone is prepared for. 如果你真的关心你所提供的产品的质量, 然后检查并挑战表面之下的东西, 多个层次上的关系和依赖关系. 最终的产品总是所有组件的集合, 工作方式, 在其生命周期中涉及的检查和程序, and we will only be able to secure it once we achieve full visibility into the weaknesses and improvement opportunities across all these parts.
