4、操作风险不能听之任之
不是所有可识别的软件供应链中的风险可以通过记录为cve的已知漏洞来识别。过时或不活动的组件可能会给您的应用程序带来没有人有理由调查的风险。然而，这些组件仍然可能潜藏着威胁。
安全团队和开发人员还必须能够识别和评估来自组件的操作风险——没有CVE记录但仍可能危及您的组织的开源软件。
4大操作风险因素
完全保护您的软件供应链，在使用开源组件时，您需要考虑以下四大操作性开源风险因素:
生命的终结
如果组件的作者已经声明它的生命周期已经结束，那么风险就很高，您不应该让它继续工作。
如果组件已经过时，同样的规则也适用。虽然开源软件可能仍然可以完成您需要它完成的工作，但它的故意忽视意味着它不再被主动监视漏洞。即使发现了任何安全漏洞，也不会发布修复它的新版本。
版本的年龄
较旧的代码往往不太安全。不仅旧的组件(即使是最新的可用版本)没有可供您利用的改进，而且它自己的依赖项可能是旧的组件，同样有风险。
代码越老，风险就越大。在JFrog，我们认为任何超过10个月但小于20个月的版本都是低风险的，而超过3年(40个月)的版本则被认为是高风险的。
版本的货币
除了一些例外，您应该始终尝试使用任何组件的最新版本，以利用所有最新的改进。这还有助于避免在早期未修复的版本中发现漏洞。
一个只落后一两个版本的组件版本——只要它是最近的——就没有真正的风险。然而，如果比这更过时，风险就会成比例地上升。一个组件比使用的版本更新四个版本被认为是中等风险，而落后六个或更多版本则是高风险。
项目健康
健康的开源项目来自健康的社区，这可以从几个贡献者的高水平活动中看出。由一个人维护的不经常更新的组件不太可能从相同程度的改进、监督或警惕中受益。更糟糕的是，这个项目似乎已经被放弃了。
开源软件项目依赖于一个积极参与的开发人员社区，他们致力于使用和改进开源软件。的Kubernetes例如，该项目有超过3100名贡献者，每年帮助生成三个dot版本和数十个补丁版本。
以下是您在评估项目的健康状况时应该考虑的主要指标:
- 释放节奏一个最低限度健康的项目每年应该至少产生2个GA版本(点或补丁)。每年只发布一个版本——或者更糟，没有发布——的项目应该被认为是不健康的。
- 提交频率-一个健康的项目在过去12个月内应该有超过100次提交。低于这个数值就被认为是不健康的。
- 每年的贡献者-该项目应在过去12个月内至少有5个不同贡献者的提交被认为是最低限度的健康。再少一点都是不健康的数字。
提高你的胜算
在您的软件供应链中检测这些操作风险应该是您的工作的一部分DevSeOps实践．除了识别已知漏洞和确保许可策略遵从性外，还需要在您的系统中筛选这些操作风险软件物料清单(SBOM)帮助完成一个全面的安全态势。
JFrog x光的软件组件分析(SCA)让事情变得简单。和你一起安全和license策略，你可以配置操作风险策略指定要查找的内容。
您可以使用JFrog的最小风险默认值从这些操作风险因素中自动计算严重性，或者指定您自己的阈值。
当你为手表分配策略对于密钥存储库，Xray将检测哪些组件违反了它们，以便您可以采取行动。
想看更多吗?要求x光片演示．
