Skip to content

Vulnerable Dependency Management Cheat Sheet / 易受攻击的依赖关系管理速查表

Introduction / 介绍

The objective of the cheat sheet is to provide a proposal of approach regarding the handling of vulnerable third-party dependencies when they are detected, and this, depending on different situation.

速查表的目标是提供一个关于处理检测到的易受攻击第三方依赖关系的建议方法，这取决于不同的情况。

The cheat sheet is not tools oriented but it contains a tools section informing the reader about free and commercial solutions that can be used to detect vulnerable dependencies, depending on the level of support on the technologies at hand

速查表不是以工具为导向的，但它包含一个工具部分，向读者介绍可以用于检测易受攻击依赖关系的免费和商业解决方案，具体取决于对现有技术的支持水平。

Note:

注意：

Proposals mentioned in this cheat sheet are not silver-bullet (recipes that work in all situations) yet can be used as a foundation and adapted to your context.

本速查表中提到的建议并非万能良方（在所有情况下都适用的方案），但可以作为基础并适应您的环境。

Context / 上下文

Most of the projects use third-party dependencies to delegate handling of different kind of operations, e.g. generation of document in a specific format, HTTP communications, data parsing of a specific format, etc.

大多数项目使用第三方依赖关系来委托处理不同类型的操作，例如：生成特定格式的文档、HTTP通信、特定格式的数据处理等。

It's a good approach because it allows the development team to focus on the real application code supporting the expected business feature. The dependency brings forth an expected downside where the security posture of the real application is now resting on it.

这是一个好的方法，因为它允许开发团队能够专注于支持预期业务功能的实际应用程序代码。依赖关系带来一个预期的缺点，即实际应用程序的安全态势现在依赖于它。

This aspect is referenced in the following projects:

以下项目引用了这一方面：

Based on this context, it's important for a project to ensure that all the third-party dependencies implemented are clean of any security issue, and if they happen to contain any security issues, the development team needs to be aware of it and apply the required mitigation measures to secure the affected application.

基于此背景，确保所有实施的三方依赖项不含有任何安全问题非常重要，如果它们确实存在安全问题，开发团队需要意识到这一点，并采取必要的缓解措施来保护受影响的应用程序。

It's highly recommended to perform automated analysis of the dependencies from the birth of the project. Indeed, if this task is added at the middle or end of the project, it can imply a huge amount of work to handle all the issues identified and that will in turn impose a huge burden on the development team and might to blocking the advancement of the project at hand.

强烈建议从项目一开始就进行依赖项的自动化分析。实际上，如果这项任务在项目中间或结束时才添加，那么处理所有识别出的问题将需要大量的工作，这反过来又会给开发团队带来巨大的负担，甚至可能阻碍当前项目的进展。

Note:

注意：

In the rest of the cheat sheet, when we refer to development team then we assume that the team contains a member with the required application security skills or can refer to someone in the company having these kind of skills to analyze the vulnerability impacting the dependency.

在接下来的速查表中，当我们提到 开发团队 时，我们假设该团队包含具有所需应用安全技能的成员，或者可以指公司内部具有这些技能的人来分析影响依赖项的漏洞。

Remark about the detection / 关于检测的说明

It's important to keep in mind the different ways in which a security issue is handled after its discovery.

在发现安全问题后，重要的是要记住处理安全问题的不同方式。

1. Responsible disclosure / 1. 负责任地披露

See a description here.

请参阅此处的描述。

A researcher discovers a vulnerability in a component, and after collaboration with the component provider, they issue a CVE (sometimes a specific vulnerability identifier to the provider is created but generally a CVE identifier is preferred) associated to the issue allowing the public referencing of the issue as well as the available fixation/mitigation.

研究人员发现组件中的一个漏洞，并与组件提供商合作后，他们发布了一个与问题相关的 CVE（有时为提供商创建一个特定的漏洞标识符，但通常更倾向于使用 CVE 标识符）允许公众引用该问题以及可用的修复/缓解措施。

If in case the provider doesn't properly cooperate with the researcher, the following results are expected:

如果提供商没有与研究人员适当合作，以下结果是可以预期的：

  • CVE gets accepted by the vendor yet the provider refuses to fix the issue.
    中文：CVE 被供应商接受，但提供商 拒绝修复问题。
  • Most of the time, if the researcher doesn't receive back a response in 30 days, they go ahead and do a full disclosure of the vulnerability.
    中文：大多数情况下，如果研究人员在 30 天内没有收到回复，他们将进行 完全披露 漏洞。

Here, the vulnerability is always referenced in the CVE global database used, generally, by the detection tools as one of the several input sources used.

在这里，漏洞总是被引用在使用的 CVE 全球数据库 中，通常作为检测工具使用的多个输入源之一。

2. Full disclosure / 2. 完全披露

See a description here, into the section named Computers about Computer Security.

请参阅关于 计算机安全 的 计算机 部分的描述 这里。

The researcher decides to release all the information including exploitation code/method on services like Full Disclosure mailing list, Exploit-DB.

研究人员决定在 Full Disclosure 邮件列表、Exploit-DB 等服务上发布所有信息，包括利用代码/方法。

Here a CVE is not always created then the vulnerability is not always in the CVE global database causing the detection tools to be potentially blind about unless the tools use other input sources.

在这里，不一定总是创建 CVE，因此漏洞不一定总是在 CVE 全球数据库中，这可能导致检测工具在没有使用其他输入源的情况下可能无法检测到。

Remark about the security issue handling decision / 关于安全问题处理决策的备注

When a security issue is detected, it's possible to decide to accept the risk represented by the security issue. However, this decision must be taken by the Chief Risk Officer (fallback possible to Chief Information Security Officer) of the company based on technical feedback from the development team that have analyzed the issue (see the Cases section) as well as the CVEs CVSS score indicators.

当检测到安全问题时，可以决定接受安全问题所代表的风险。然而，此决策必须由公司的高级风险官（CRO）根据开发团队对问题的技术反馈（见 案例 部分）以及CVEs CVSS评分指标做出。如果可能，此决策可由首席信息安全官（CISO）做出。

Cases / 案例

When a security issue is detected, the development team can meet one of the situations (named Case in the rest of the cheat sheet) presented in the sub sections below.

当检测到安全问题时，开发团队可能会遇到以下子部分中提到的以下情况（在其余的cheat sheet中称为 Case）。

If the vulnerably impact a transitive dependency then the action will be taken on the direct dependency of the project because acting on a transitive dependency often impact the stability of the application.

如果漏洞影响传递依赖，则将对项目的直接依赖项采取行动，因为对传递依赖项采取行动通常会影响到应用程序的稳定性。

Acting on a on a transitive dependency require the development team to fully understand the complete relation/communication/usage from the project first level dependency until the dependency impacted by the security vulnerability, this task is very time consuming.

对传递依赖项采取行动需要开发团队首先完全理解从项目一级依赖项到受安全漏洞影响的依赖项的完整关系/通信/使用，这项任务非常耗时。

Case 1 / 案例1

Context / 上下文

Patched version of the component has been released by the provider.

组件的修补版本已由提供商发布。

Ideal condition of application of the approach / 应用此方法的理想条件

Set of automated unit or integration or functional or security tests exist for the features of the application using the impacted dependency allowing to validate that the feature is operational.

存在针对应用程序功能使用受影响依赖项的自动化单元或集成或功能或安全测试集，以验证该功能是否正常运行。

Approach / 方法

Step 1:

步骤 1:

Update the version of the dependency in the project on a testing environment.

在测试环境中更新项目的依赖项版本。

Step 2:

步骤 2:

Prior to running the tests, 2 output paths are possible:

在运行测试之前，可能存在两种输出路径：

  • All tests succeed, and thus the update can be pushed to production.
    中文：所有测试成功，因此更新可以推送到生产环境。
  • One or several tests failed, several output paths are possible:
    中文：一个或多个测试失败，可能存在多个输出路径：
    • Failure is due to change in some function calls (e.g. signature, argument, package, etc.). The development team must update their code to fit the new library. Once that is done, re-run the tests.
      中文：失败是由于某些函数调用（例如：签名、参数、包等）的变化。开发团队必须更新他们的代码以适应新的库。完成此操作后，重新运行测试。
    • The fixed version cannot be adopted at all (e.g. the fix only ships in a new major version that breaks the application, or the vulnerable version is pinned by a transitive dependency). Apply Case 5, using Case 2 as an interim mitigation.
      中文：无法采用修复后的版本（例如：修复仅在新的大版本中提供，这会破坏应用程序，或者易受攻击的版本被传递依赖项锁定）。应用案例5，在等待提供者反馈的同时使用案例2作为临时缓解措施。
    • Technical incompatibility of the released dependency (e.g. require a more recent runtime version) which leads to the following actions:
      中文：发布依赖项的技术不兼容（例如：需要更近期的运行时版本）导致以下操作： 1. Raise the issue to the provider.
      中文：向提供者提出问题。 2. Apply Case 2 while waiting for the provider's feedback.
      中文：在等待提供者反馈的同时应用案例2。

Case 2 / 案例2

Context / 上下文

Provider informs the team that it will take a while to fix the issue and, so, a patched version will not be available before months.

提供者通知团队修复问题需要一段时间，因此修补版本在数月内无法提供。

Ideal condition of application of the approach / 应用此方法的理想条件

Provider can share any of the below with the development team:

提供者可以与开发团队分享以下任何内容：

  • The exploitation code.
    中文：利用代码。
  • The list of impacted functions by the vulnerability.
    中文：受漏洞影响的函数列表。
  • A workaround to prevent the exploitation of the issue.
    中文：防止利用该问题的解决方案。

Approach / 方法

Step 1:

步骤 1:

If a workaround is provided, it should be applied and validated on the testing environment, and thereafter deployed to production.

如果提供了解决方案，应在测试环境中应用和验证，然后部署到生产环境。

Identify the reachable calls to affected functions and the conditions required to exploit the vulnerability. Use a wrapper only when its checks block those conditions on every affected call path. Otherwise, disable the affected functionality or isolate it while pursuing a fix. Treat the wrapper as a temporary mitigation, and track the upgrade or replacement that removes the vulnerable dependency.

识别受影响的函数的可达调用和利用漏洞所需的条件。仅在检查阻止每个受影响调用路径上的条件时才使用包装器。否则，禁用受影响的功能或将其隔离，同时寻求修复。将包装器视为临时缓解措施，并跟踪升级或替换以移除易受攻击的依赖项。

Moreover, security devices, such as the Web Application Firewall (WAF), can handle such issues by protecting the internal applications through parameter validation and by generating detection rules for those specific libraries. Yet, in this cheat sheet, the focus is set on the application level in order to patch the vulnerability as close as possible to the source.

此外，安全设备，如Web应用防火墙（WAF），可以通过参数验证保护内部应用程序，并为特定库生成检测规则来处理此类问题。然而，在本速查表中，重点放在应用层面，以便尽可能接近源头修补漏洞。

Illustrative allowlist wrapper: use this only if analysis of the specific vulnerability establishes that the accepted values cannot trigger it. This pattern is not a general defense against remote code execution.

示例允许列表包装器：仅在分析特定漏洞确定接受值不会触发它时使用。此模式不是针对远程代码执行的通用防御措施。

public void callFunctionWithRCEIssue(String externalInput){
    //Apply input validation on the external input using regex
    if(Pattern.matches("[a-zA-Z0-9]{1,50}", externalInput)){
        //Call only with values covered by the vulnerability-specific analysis
        functionWithRCEIssue(externalInput);
    }else{
        //Log rejected input without assuming it was an exploit
        SecurityLogger.warn("Input rejected by temporary vulnerability mitigation");
        //Raise an exception leading to a generic error send to the client...
    }
}

If the provider has provided nothing about the vulnerability, Case 3 can be applied skipping the step 2 of this case. We assume here that, at least, the CVE has been provided.

如果提供商没有提供有关漏洞的任何信息，可以应用案例3，跳过本案例的_step 2_。我们假设至少提供了CVE。

Step 2:

步骤 2:

Use any provider-supplied exploit as a regression test. Blocking that payload does not prove that the library is secure: test alternate inputs and all reachable paths to the affected functionality. The Core Rule Set rule-writing guidance illustrates how small payload changes can bypass a filter. Follow the virtual patch testing guidance and keep the permanent fix on the remediation plan.

使用供应商提供的漏洞作为回归测试。阻止该有效载荷并不能证明库是安全的：测试所有可到达受影响功能的替代输入和所有路径。核心规则集规则编写指南说明了小的有效载荷更改如何绕过过滤器。遵循虚拟补丁测试指南并保持永久修复在修复计划中。

If you have a set of automated unit or integration or functional or security tests that exist for the application, run them to verify that the protection code added does not impact the stability of the application.

如果您有一套针对应用程序的自动化单元或集成或功能或安全测试，运行它们以验证添加的保护代码不会影响应用程序的稳定性。

Add a comment in the project README explaining that the issue (specify the related CVE) is handled during the waiting time of a patched version because the detection tool will continue to raise an alert on this dependency.

在项目README中添加注释，说明该问题（指定相关的CVE）在补丁版本等待期间得到处理，因为检测工具将继续对此依赖项发出警报。

Note: You can add the dependency to the ignore list but the ignore scope for this dependency must only cover the CVE related to the vulnerability because a dependency can be impacted by several vulnerabilities having each one its own CVE.

注意：您可以将依赖项添加到忽略列表，但此依赖项的忽略范围必须仅涵盖与漏洞相关的CVE，因为依赖项可能受到多个漏洞的影响，每个漏洞都有自己的CVE。

Case 3 / 案例3

Context / 上下文

Provider informs the team that they cannot fix the issue, so no patched version will be released at all (applies also if provider does not want to fix the issue or does not answer at all).

供应商通知团队他们无法修复该问题，因此根本不会发布任何修补版本（也适用于供应商不想修复问题或根本不回答的情况）。

In this case the only information given to the development team is the CVE.

在这种情况下，提供给开发团队的唯一信息是CVE。

Notes:

注意：

  • This case is really complex and time consuming and is generally used as last resort.
    中文：此案例非常复杂且耗时，通常作为最后的手段使用。
  • If the impacted dependency is an open source library then we, the development team, can create a patch and create pull request - that way we can protect our company/application from the source as well as helping others secure their applications.
    中文：如果受影响的依赖项是开源库，那么我们，即开发团队，可以创建补丁并创建 拉取请求 - 这样我们不仅可以保护我们的公司/应用程序，还可以帮助他人保护他们的应用程序。

Ideal condition of application of the approach / 应用此方法的理想条件

Nothing specific because here we are in a patch yourself condition.

没有具体的原因，因为我们现在处于一个需要自己修复的情况。

Approach / 方法

Step 1:

步骤 1:

If we are in this case due to one of the following conditions, it's a good idea to start a parallel study to find another component better maintained or if it's a commercial component with support then put pressure on the provider with the help of your Chief Risk Officer (fallback possible to Chief Information Security Officer):

如果我们处于以下情况之一，开始一个并行研究以寻找维护更好的其他组件，或者如果它是带有支持的商业组件，那么在您的首席风险官的帮助下对提供商施加压力（可能的回退到首席信息安全官)是个好主意：

  • Provider does not want to fix the issue.
    中文：提供商不想修复这个问题。
  • Provider does not answer at all.
    中文：提供商完全不予回应。

In all cases, here, we need to handle the vulnerability right now.

在所有情况下，我们都需要立即处理这个漏洞。

Step 2:

步骤 2:

As we know the vulnerable dependency, we know where it is used in the application (if it's a transitive dependency then we can identify the first level dependency using it using the IDE built-in feature or the dependency management system used (Maven, Gradle, NuGet, npm, etc.). Note that IDE is also used to identify the calls to the dependency.

既然我们知道有漏洞的依赖项，我们就知道它在应用程序中的使用位置（如果它是传递依赖项，则可以使用IDE的内置功能或使用的依赖项管理系统（Maven、Gradle、NuGet、npm等）来识别第一级依赖项）。请注意，IDE也用于识别对依赖项的调用。

Identifying calls to this dependency is fine but it is the first step. The team still lacks information on what kind of patching needs to be performed.

识别对这一依赖项的调用是好的，但这只是第一步。团队仍然缺乏关于需要执行何种修补操作的信息。

Use the CVE description to identify the reported weakness, then consult the upstream advisory, issue, and fix to determine the affected behavior and required change. A vulnerability category alone does not establish which checks or configuration changes will prevent exploitation. If the root cause is still unclear, do not assume that a wrapper from Case 2 fixes it.

使用 CVE 描述来识别报告的弱点，然后咨询上游通告、问题和修复，以确定受影响的行为和所需更改。仅凭漏洞类别并不能确定哪些检查或配置更改可以防止利用。如果根本原因仍然不明确，不要假设 案例 2 中的包装可以修复它。

Example:

例子：

The team has an application using the Jackson API in a version exposed to the CVE-2016-3720.

团队正在使用一个使用 Jackson API 的应用程序，该应用程序的版本暴露于 CVE-2016-3720。

The description of the CVE is as follows:

CVE 的描述如下：

XML external entity (XXE) vulnerability in XmlMapper in the Data format extension for Jackson
(aka jackson-dataformat-xml) allows attackers to have unspecified impact via unknown vectors.

The upstream issue and fix disable XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES for input factories created by Jackson. This is a parser configuration change, not generic XML pre-validation. Use a maintained release containing the fix. If an upgrade is blocked, evaluate that specific fix through Case 5; also harden any application-supplied parser using the XXE prevention guidance.

上游问题 链接 和 修复 禁用了 Jackson 创建的输入工厂的 XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES。这是一个解析器配置更改，而不是通用的 XML 预验证。使用包含修复的维护版本。如果升级受阻，通过 案例 5 评估该特定修复；同时，使用 XXE 防止指南强化任何由应用程序提供的解析器。

Step 3:

步骤 3：

If possible, create a unit test that mimics the vulnerability in order to ensure that the patch is effective and have a way to continuously ensure that the patch is in place during the evolution of the project.

如果可能，创建一个模拟漏洞的单元测试，以确保补丁有效，并有一种方法在项目演变过程中持续确保补丁到位。

If you have a set of automated unit or integration or functional or security tests that exists for the application then run them to verify that the patch does not impact the stability of the application.

如果您有一套针对应用程序的自动化单元或集成或功能或安全测试，则运行它们以验证补丁不会影响应用程序的稳定性。

A patch written in-house does not get the benefit of the doubt that an upstream release gets, so hold it to an explicit bar before considering the vulnerability handled:

内部编写的补丁不会得到上游发布所获得的信任利益，因此在考虑漏洞已处理之前，将其与明确的基准保持一致。

  • The test reproducing the vulnerability fails against the unpatched dependency and passes against the patched one. A test that passes in both cases proves nothing about the patch.
    中文：测试复现漏洞在未打补丁的依赖项上失败，而在已打补丁的依赖项上通过。在两种情况下都通过测试并不能证明补丁的有效性。
  • The tests of the dependency itself still pass, which catches behavior that the patch broke but the application does not exercise directly.
    中文：依赖项本身的测试仍然通过，这可以捕捉到补丁破坏了但应用程序没有直接使用的功能。
  • The alert raised by the detection tool is suppressed per CVE only once the two points above hold. Suppressing the alert, or changing a version string so that the tool stops matching it, records a fix but does not make one.
    中文：检测工具引发的警报只有在上述两点成立后才会被抑制。抑制警报或更改版本字符串以使工具停止匹配，记录了一个修复，但并没有真正修复。

Expect the tool to keep flagging the dependency even after a correct patch, because looking at the version number of a package will not tell you whether the fix is present. That is a reporting problem to be handled with a scoped suppression, not a reason to change the patch.

预期工具即使在正确的补丁之后也会继续标记依赖项，因为查看软件包的版本号并不能告诉你修复是否已经存在。这是一个需要通过范围抑制来处理的问题报告，而不是改变补丁的理由。

Case 4 / 案例4

Context / 上下文

The vulnerable dependency is found during one of the following situation in which the provider is not aware of the vulnerability:

在以下情况下发现存在漏洞的依赖项，而提供者并不知道这个漏洞：

  • Via the discovery of a full disclosure post on the Internet.
    中文：通过在互联网上发现一个完整的披露帖子。
  • During a penetration test.
    中文：在渗透测试期间。

Ideal condition of application of the approach / 应用此方法的理想条件

Provider collaborates with you after being notified of the vulnerability.

在被告知漏洞后，提供者与你合作。

Approach / 方法

Step 1:

步骤 1:

Inform the provider about the vulnerability by sharing the post with them.

通过与他们分享帖子来通知提供商关于该漏洞的信息。

Step 2:

步骤 2:

Using the information from the full disclosure post or the pentester's exploitation feedback, if the provider collaborates then apply Case 2, otherwise apply Case 3, and instead of analyzing the CVE information, the team needs to analyze the information from the full disclosure post/pentester's exploitation feedback.

使用完整披露帖子或渗透测试员的利用反馈中的信息，如果提供商合作，则应用案例2，否则应用案例3，并且不需要分析CVE信息，团队需要分析完整披露帖子/渗透测试员的利用反馈中的信息。

Case 5 / 案例5

Context / 上下文

A fixed version has been released by the provider, but the project cannot adopt it:

提供商已发布修复版本，但项目无法采用它：

  • The fix only ships in a new major version that breaks the application code.
    中文：修复仅在新的大版本中提供，这会破坏应用程序代码。
  • The vulnerable version is pinned by a transitive dependency that has not been updated yet.
    中文：有漏洞的版本被一个尚未更新的 传递依赖 锁定。
  • The version line in use is no longer maintained and the fix landed only on a newer line.
    中文：正在使用的版本行不再维护，修复仅在新版本行上实现。

This is not Case 3: the fix exists and is public, so nothing has to be invented, but it has to be moved onto the version line that the project can actually run. That practice is called backporting, and operating system vendors have handled the same problem this way for years. Debian states that "instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release", and Red Hat defines backporting as "the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version".

这不是案例3：修复存在且是公开的，因此不需要发明任何东西，但它必须转移到项目实际上可以运行的版本行上。这种做法称为_backporting_，操作系统供应商多年来一直以这种方式处理相同的问题。Debian表示“我们不是升级到新版本，而是将安全修复程序回滚到稳定版本中发布的版本”，Red Hat将回滚定义为“从上游软件包的最新版本中提取安全漏洞的修复程序并将其应用于旧版本”。

Ideal condition of application of the approach / 应用此方法的理想条件

The upstream fix can be identified (a commit, a patch file, or an advisory precise enough to locate the change), the source of the version in use is available, and automated tests exist for the application features using the dependency.

可以识别上游修复（一个提交、一个补丁文件或足够精确的咨询以定位更改），可用的是正在使用的版本源，并且存在针对应用程序功能的依赖项的自动化测试。

Approach / 方法

Step 1:

步骤 1:

Confirm that the upgrade is really blocked by attempting it on a testing environment as described in Case 1. Backporting is cheaper than a major upgrade in the short term and more expensive over the life of the project, so it must be a deliberate choice rather than the first reflex. Record the exact blocker (breaking API, transitive pin, unsupported runtime), because that is the condition to re-test later.

确认升级确实如案例1中所述在测试环境中受阻。短期来看，回滚比重大升级更经济，但从项目生命周期来看则更昂贵，因此它必须是一个深思熟虑的选择，而不是本能反应。记录确切的阻碍因素（破坏API、传递性依赖、不支持的运行时），因为这将是稍后重新测试的条件。

Step 2:

步骤 2:

Isolate the security-relevant change from the rest of the upstream release. Fix commits are frequently bundled with refactoring, renaming and unrelated bugfixes that must not be carried over, and the fix may rely on internal functions that do not exist in the older line, in which case the same check has to be re-implemented instead of cherry-picked. Keep the patch minimal: the goal is to block the vulnerability without changing any existing legitimate behavior.

将安全相关的变更与上游版本的其他部分隔离。修复提交通常与重构、重命名和不相关的错误修复捆绑在一起，这些修复不应被携带，并且修复可能依赖于在旧版本中不存在的内部函数，在这种情况下，必须重新实现相同的检查而不是 cherry-pick。保持补丁最小：目标是阻止漏洞，而不改变任何现有的合法行为。

Step 3:

步骤 3：

Verify the patch rather than assume it. A test reproducing the vulnerability must fail against the unpatched dependency and pass against the patched one, and both the dependency's own test suite and the application tests must still pass. Silencing the scanner or bumping a version string is not remediation.

验证补丁而不是假设它。一个重现漏洞的测试必须在未修补的依赖项上失败，在修补的依赖项上通过，并且依赖项自己的测试套件和应用程序测试仍然必须通过。静音扫描器或提升版本字符串不是补救措施。

Step 4:

步骤4：

Distribute the patched artifact so that every build resolves it: publish it to the internal registry or proxy that the build already trusts, instead of committing a locally built file into each project. Give it a version identifier that remains traceable to the upstream version it derives from, and record its provenance (source commit, CVE, who produced it) so that the next reader can audit it. Expect detection tools to keep flagging the dependency, because looking at the version number of a package will not tell you whether a backported fix is present; suppress the alert per CVE as described in the note of Case 2.

分发修补后的工件，以便每个构建都能解决它：将其发布到构建已经信任的内部注册表或代理，而不是将本地构建的文件提交到每个项目。给它一个版本标识符，该标识符可以追溯到它从中派生的上游版本，并记录其来源（源提交、CVE、谁生产的它），以便下一个读者可以审计它。预计检测工具将继续标记依赖项，因为查看包的版本号不会告诉你是否存在回滚修复；根据案例2的说明按CVE抑制警报。

Step 5:

步骤5：

Treat the patch as a standing commitment and not a one-off task. Every new upstream release of the dependency has to be re-patched, and every new CVE affecting it adds another patch to carry. Before deciding to maintain patches in-house, size that recurring work against acquiring maintained backports from a provider whose business is producing them. Drop the backport as soon as the fixed version becomes adoptable: re-test the blocker recorded in step 1 at each dependency review, then go back to Case 1.

将补丁视为一项持续承诺，而不是一次性任务。每个依赖项的新上游版本都必须重新修补，每个影响它的新的CVE都会增加另一个需要携带的补丁。在决定在内部维护补丁之前，将这项重复工作与从生产这些补丁的业务提供商那里获取维护的回滚补丁进行比较。一旦修复的版本变得可接受，就丢弃回滚：在每个依赖项审查时重新测试步骤1中记录的阻碍因素，然后回到案例1。

Tools / 工具

This section lists several tools that can used to analyze the dependencies used by a project in order to detect the vulnerabilities.

本节列出了可以用来分析项目使用的依赖项以检测漏洞的几个工具。

It's important to ensure, during the selection process of a vulnerable dependency detection tool, that this one:

在选择漏洞依赖检测工具的过程中，确保这一点非常重要：

  • Uses several reliable input sources in order to handle both vulnerability disclosure ways.
    中文：使用多个可靠的输入源以处理两种漏洞披露方式。

  • Support for flagging an issue raised on a component as a false-positive.
    中文：支持将组件上提出的问题标记为 误报。

  • Free
    中文：免费

    • OWASP Dependency Check) （OWASP 依赖性检查）:
      • Full support: Java, .Net.
        中文：全面支持：Java, .Net。
      • Experimental support: Python, Ruby, PHP (composer), NodeJS, C, C++.
        中文：实验性支持：Python, Ruby, PHP (composer), NodeJS, C, C++。
    • NPM Audit) （NPM 审计）
      • Full support: NodeJS, JavaScript.
        中文：全面支持：NodeJS, JavaScript。
      • HTML report available via this module.
        中文：HTML 报告可通过此 模块 获取。
    • OWASP Dependency Track) （OWASP 依赖性跟踪） can be used to manage vulnerable dependencies across an organization.
    • Trivy
      • Full support: Base OS, Java, NodeJS, JavaScript, Ruby, Python, Go, .NET, Rust, PHP, Dart, Swift
        中文：全面支持：基础操作系统、Java、NodeJS、JavaScript、Ruby、Python、Go、.NET、Rust、PHP、Dart、Swift
      • Targets: Kubernetes (nodes and containers), Docker (nodes and containers), filesystem, Git repositories, cloud images
        中文：目标：Kubernetes（节点和容器）、Docker（节点和容器）、文件系统、Git 仓库、云镜像
    • Grype
      • Full support across mainstream language ecosystems with SBOM-driven scanning
        中文：通过 SBOM 驱动的扫描全面支持主流语言生态系统
      • Targets: container images, filesystems, and SBOMs produced by Syft
        中文：目标：容器镜像、文件系统以及由 Syft 生成的 SBOM。
  • Commercial
    中文：商业版
    • Snyk (open source and free option available):
      • Full support) （全面支持） for many languages and package manager.
    • JFrog XRay:
      • Full support) （全面支持） for many languages and package manager.
    • Renovate (allow to detect old dependencies):
      • Full support) （全面支持） for many languages and package manager.

Remediation and maintained backports / 修复和维持回滚版本

The tools above detect vulnerable dependencies, they do not fix them. When the fixed version cannot be adopted, the patch still has to come from somewhere: either the development team maintains it or someone else does.

上述工具检测易受攻击的依赖项，但不会修复它们。当无法采用修复版本时，补丁仍然需要从某处获取：要么开发团队维护它，要么其他人维护。

Linux distribution security teams are the reference model for the second option. Debian and Red Hat both backport security fixes into the version shipped in the stable release instead of upgrading it. When the dependency is consumed as an operating system package, take the distribution's patched build rather than maintaining a private patch.

Linux 发行版安全团队是第二种选择的参考模型。Debian 和 Red Hat 都会将安全补丁回滚到稳定版本中发布的版本，而不是升级它。当依赖项作为操作系统包使用时，应使用发行版的修补构建版本，而不是维护私有补丁。

Language ecosystem packages are rarely covered that way, so the choice there is between maintaining the patch in-house and paying someone to maintain it. Judge either option on the same criteria as a detection tool, plus:

语言生态系统包很少以这种方式覆盖，因此在内部维护补丁或支付他人维护之间的选择。根据与检测工具相同的标准判断这两种选择，此外：

  • Coverage of the ecosystems, version lines and severities the project depends on, with a published response time.
    中文：覆盖生态系统、版本线和项目依赖的严重性，以及已发布的响应时间。
  • Publication of the patch itself and of its provenance, so that the change can be reviewed instead of being trusted blindly.
    中文：补丁及其来源的发布，以便可以审查更改而不是盲目信任。
  • Delivery as a compatible artifact through a registry or proxy that the build already uses, so that no manifest rewrite is required.
    中文：通过已使用的注册表或代理作为兼容的工件交付，因此无需重写清单。
  • A documented way out, so that leaving the source does not mean re-patching everything from scratch.
    中文：有文档记录的退出方式，以便离开源代码并不意味着需要从头开始重新打补丁。

References / 参考