TL博士
查找 npm 包漏洞很容易。 npm audit 只需四秒钟，就能给你 400 条结果。 难点在于接下来的两个问题：你的应用程序中实际可以访问哪些功能，以及哪个升级可以在不破坏构建的情况下解决问题。
- 清单上的大部分内容都与你无关。 将可达性和运行时上下文应用于“关键”发现后，仍然只有一小部分发现是关键的。调用图分析可以告诉你哪些是关键发现。
npm audit fix --force这不是一种万全之策。 它通过跳过主要版本来解决安全问题，这就是安全任务变成服务中断的原因。- 传递依赖关系是体积所在。 它们不是你选择的，你通常不能直接升级它们，而且它们在发现数量中占据主导地位。
- 请在合并之前修复，而不是在发布之后。 CI 中的门和自动化 pull request 只需几分钟。一个生产补丁却要花一个周末。
为什么发现的数量不是问题所在
每个运行超过一年的 Node 项目都会带来同样的体验。你运行一次扫描，会发现数百个 npm 包漏洞，列表如此之长，以至于理智的做法是关闭终端。
这种反应是正确的，而这正是令人不安的地方。近四分之三的代码库都包含高风险的开源组件，扫描器每天报告的大部分问题实际上都存在于你的依赖树中。列表是准确的，但它并非待办事项清单。
准确的清单和可执行的清单之间的差距在于背景，而这最终取决于几个问题。
- 我的应用程序是否真的可以访问到存在漏洞的代码？
- 有人在实际应用中利用这个漏洞吗？
- 它所影响的事物对企业来说重要吗？
一台无法回答这些问题的扫描仪，却给你一份库存清单，并称之为报告。
如何检查 npm 包的漏洞
检查 npm 包是否存在漏洞有四种实用方法，它们回答了不同的问题。
开始 npm audit 因为它不花钱，只需几秒钟。但不要就此止步，因为它给出的答案是“这里应有尽有”，而“应有尽有”并不等同于计划。
如果您依赖安全公告源，那么有一点值得注意：GitHub 安全公告数据库包含针对 npm 生态系统的恶意软件安全公告，但 Dependabot 故意不针对这些公告发出警报，因为下游用户通常无法通过升级来解决这些问题。这是一个结构性缺陷，并非您可以开启的设置。恶意软件包需要不同的控制措施：在发布时进行检测，而不是在泄露后进行检测。Xygeni 的 恶意软件预警 它会在软件包发布的第一时间，通过行为分析和异常分析，而非等待签名，对 npm、PyPI、Maven 和其他注册表中新发布的软件包进行分析。这项功能包含在免费的开发者计划中。我们将在下文中详细介绍它。 恶意 npm 包。
将 400 条搜索结果筛选成简短列表的筛选条件
这部分会改变团队的运作方式。
| 筛选 | 它回答的问题 | 它通常会移除什么 |
|---|---|---|
| 可达性 | 我的应用程序执行过程真的能到达存在漏洞的函数吗？ | 最大幅度的削减。大多数建议都存在于应用程序永远不会调用的代码中。 |
| 漏洞利用可用性 | 是否存在可用的公开漏洞利用程序，以及该漏洞目前是否正在被实际利用？ | 将理论风险与武器化风险区分开来。无论严重程度评分如何，一旦发现存在公开漏洞，该漏洞就会优先处理。 |
| 利用可能性（EPSS） | 未来 30 天内，野生动物遭受剥削的可能性有多大？ | 本周的工作中很少会遇到无人利用的高危漏洞。 |
| 商业环境 | 受影响的服务重要吗？它是否暴露在外？ | 在不涉及任何实质性风险的系统中，可获取且可利用的发现 |
| 可用性 | 有没有一种版本既能解决这个问题又不会让我的系统崩溃？ | 区分哪些工作今天就能完成，哪些工作需要变通办法。 |
- 可达性 这是第一道也是最重要的一道工序。你所依赖的软件包中的漏洞只有在执行能够实际到达存在漏洞的函数时才能被利用。调用图追踪可以在函数级别而非清单文件中进行猜测，从而区分你真正使用的组件和仅仅存在的组件。Xygeni 的可达性分析可以将误报率降低高达 70%。
漏洞利用可用性 第二点是，这并非预测，而是既成事实。一个公开可用的漏洞利用程序，或者已确认的在实际环境中被利用的漏洞，会改变漏洞发现的优先级，无论其严重性评分如何。这种区分已不再是良好实践，而成为一项义务：根据《网络弹性法案》，制造商一旦发现其产品中存在已被积极利用的漏洞，必须在24小时内提交报告。如果一个程序无法区分“已被积极利用”和“高CVSS评分”，就无法满足这一时限要求。
漏洞利用可能性是第三个问题，它与第一个问题类似，只是重新加入了预测。EPSS 评分衡量的是漏洞在未来 30 天内被实际利用的概率，这与漏洞一旦被利用会造成多大的危害是截然不同的两回事。CVSS 评分高而 EPSS 评分低的情况很少见。
- 商业环境 第三种情况，也是任何通用信息源都无法提供的。互联网支付服务中可访问、可利用的漏洞，与内部报告工具中同一个 CVE 编号，并非同一概念。
这些过滤器组合使用，通常能将一份无人问津的列表变成一份有人会仔细阅读的列表。运行时和可达性上下文通常只保留极少数“关键”发现仍然至关重要。Xygeni 将可达性、漏洞利用可用性、EPSS 和业务上下文视为优先级排序漏斗中的可配置阶段（最多八个），因此“可达且正在被积极利用”不再需要手动运行查询，而是一个常驻队列。
修复 npm 包漏洞而不破坏构建
发现漏洞只是第一步。npm 包漏洞之所以几个月都无法解决，是因为修复漏洞本身也存在风险，而开发者们对此心知肚明。
升级前最重要的问题不是“这个版本是否修复了CVE漏洞”，而是三个问题：哪些漏洞会在这个版本中消失，哪些新漏洞会随之出现，以及版本升级是否会破坏我的代码。
西吉尼 它会显示每个易受攻击的依赖项的所有三个选项，因此只需在可见的选项之间进行选择，而无需贸然做出决定。然后，自动修复程序会生成…… pull request 使用已打补丁的版本，批量修复功能可以在一次操作中应用多个修复程序，并且 Xygeni Bot 可以按需运行。 pull requests 或者每天，这样积压的工作量就会减少，而无需任何人安排。
对于传递依赖项，你不能简单地升级到你没有选择的版本，有用的输出是解决该建议的树中最短升级路径，而不是告诉你四级以下的软件包存在漏洞的警报。
发货前：支票应该发到哪里
“发货前”是一种进度安排的说法，归根结底就是三个位置。
- 在集成开发环境（IDE）中因此，开发人员在选择依赖项时就能发现问题，而此时更改依赖项的成本最低。
- 点击 pull request其中，机器人会评论更改内容并发布修复方案，安全门会根据超过阈值的发现结果来阻止构建。如果仅根据严重性进行门控，团队就会禁用该门控；而如果根据可访问性和可利用性发现进行门控，他们就会保留该门控。
- 发布后持续进行， 因为合并时原本安全的依赖项，一旦安全公告发布，就会变得容易受到攻击。持续监控各个注册表可以及时发现这些问题，而无需人工干预重新扫描。
这三者的输出都应该与你的输出一起放入同一个优先级队列中。 SAST, 秘密和 容器调查结果包括从您已运行的工具中摄取的那些。 漏洞列表 存在于其自身控制台中的一个列表会与它本应提供信息的工作争夺注意力。
先发布解决方案，而不是发布调查结果。
一个扫描器如果只列出 400 个 npm 包漏洞，那它并没有真正完成工作，它只是转移了工作。
Xygeni 通过可达性、利用可能性和业务背景来缩小依赖关系查找范围，显示每次升级修复了哪些问题以及可能破坏哪些问题，并打开 pull request 使用已打补丁的版本。它可以在你的……中运行。 pipeline，产生 SBOM 以及 SPDX 和 CycloneDX 中的 VDR 输出，CRA、NIS2 和 DORA 要求的证据，并将依赖性发现与其余风险放在同一个优先队列中，包括来自您不会替换的扫描器的发现。
免费开始 并扫描存储库，或者 看看可达性如何改变列表.
常见问题解答
如何检查npm包是否存在漏洞？
运行 npm audit 为了快速查看漏洞，可以使用具有可达性分析功能的工具，将列表缩小到实际可以调用漏洞代码的位置。像 OSV 和 GitHub 安全咨询数据库这样的安全咨询数据库对于检查特定软件包和版本非常有用。
Is npm audit fix 可以安全运行吗？
非强制版本通常是安全的，因为它保持在语义版本兼容的范围内。 npm audit fix --force 并非如此：它会跨主要版本进行升级以解决安全建议，而这正是导致重大变更的原因。
为什么我的 npm 包存在这么多漏洞？
因为它们大多具有传递性。你安装几个直接依赖项，却会继承数百个间接依赖项，每个间接依赖项都有自己的安全提示历史记录。数量本身没问题，问题在于缺乏有效的优先级排序。
什么是可达性分析？
确定应用程序的执行是否真的能够到达依赖项中的易受攻击函数。这是依赖项安全领域最有效的降噪方法，因为大多数已报告的漏洞都存在于应用程序永远不会调用的代码中。
我应该使用 CVSS 还是 EPSS 来确定优先级？
两者用途不同。CVSS 描述的是漏洞一旦被利用的严重程度。EPSS 则估计漏洞在未来 30 天内被利用的可能性。如果只关注严重程度而不考虑可能性，就会得到一个排序错误的队列。
我应该多久检查一次npm包是否存在漏洞？
持续进行，而非按计划进行。周一的扫描结果正常，但周三却发现某个已发货的包裹出现问题，这毫无意义。
