编辑程序包来源控制

在 Amazon 中 CodeCatalyst，可以通过直接发布软件包版本、从上游存储库中提取包版本或通过网关从外部公共存储库摄取包版本来将其添加到包存储库中。如果您允许通过直接发布和从公共存储库提取来添加软件包的版本，则您很容易受到依赖项替换攻击。有关更多信息，请参阅 依赖项替换攻击。要保护自己免受依赖关系替换攻击，请在存储库中的软件包上配置软件包来源控件，以限制将该软件包的版本添加到存储库的方式。

您应该考虑配置软件包来源控件，使不同软件包的新版本既来自内部来源（例如直接发布），也来自外部来源（例如公共存储库）。默认情况下，包源控制是根据软件包的第一个版本添加到存储库的方式来配置的。

程序包来源控制设置

使用程序包来源控制，您可以配置将程序包版本添加到存储库的方式。以下列表包括可用的程序包来源控制设置和值。

Publish

此设置配置了是否可以使用程序包管理器或类似工具将程序包版本直接发布到存储库。

• ALLOW: Package 版本可以直接发布。

• BLOCK: Package 版本不能直接发布。

上游

此设置配置了在程序包管理器发出请求时，是从外部的公有存储库中摄取程序包版本，还是在上游存储库中保留程序包版本。

• ALLOW：任何软件包版本都可以从配置为上游 CodeCatalyst 存储库的其他存储库中保留，也可以通过外部连接从公共来源获取。

• BLOCK：Package 版本不能从配置为上游 CodeCatalyst 存储库的其他存储库中保留，也不能从具有外部连接的公共来源提取。

默认程序包来源控制设置

软件包的默认软件包来源控件将基于该软件包的第一个版本添加到软件包存储库中的方式。

• 如果第一个包版本由软件包管理器直接发布，则设置将为 “发布:” ALLOW 和 “上游:BLOCK”。

• 如果第一个包版本是从公共来源提取的，则设置将为 “发布:” BLOCK 和 “上游:ALLOW”。

常见的程序包访问控制场景

本节介绍将软件包版本添加到软件 CodeCatalyst 包存储库时的一些常见场景。Package Origin 控制设置是根据第一个包版本的添加方式为新包设置的。

在以下情况下，内部软件包将直接从包管理器发布到您的存储库，例如您维护的软件包。外部包是存在于公共存储库中的包，可以通过上游的网关存储库将其提取到您的存储库中。

为现有内部程序包发布了外部程序包版本

在此场景中，考虑一个内部程序包 packageA。您的团队将 PackageA 的第一个软件包版本发布到 CodeCatalyst 软件包存储库。由于这是该程序包的第一个程序包版本，因此程序包来源控制设置会自动设置为发布：允许和上游：阻止。在您的存储库中发布软件包后，同名的包将发布到与您的软件 CodeCatalyst 包存储库连接的公共存储库中。这可能是针对内部软件包的企图依赖替换攻击，也可能是巧合。无论如何，配置程序包来源控制来阻止摄取新的外部版本，从而保护自己免受潜在的攻击。

在下图中，RepoA 是您的 CodeCatalyst 软件包存储库，与存储库有上游连接。npm-public-registry-gateway您的存储库包含 packageA 的版本 1.1 和 2.1，但版本 3.0 已发布到公有存储库。通常，RepoA 会在软件包管理器请求软件包后提取版本 3.0。由于软件包提取设置为 “阻止”，因此版本 3.0 不会提取到您的 CodeCatalyst 软件包存储库中，也无法供与其连接的包管理员使用。

已为现有外部程序包发布内部程序包版本

在这种情况下，包名为 packageB 的外部存在于您已连接到存储库的公共存储库中。当连接到您的存储库的程序包管理器请求 packageB 时，从公有存储库中将程序包版本摄取到您的存储库中。由于这是添加到存储库中的 P ackageB 的第一个软件包版本，因此软件包来源设置配置为 “发布:” BLOCK 和 “上游:ALLOW”。稍后，您尝试将具有相同程序包名称的版本发布到存储库。您可能不知道该公共软件包并试图发布一个不相关的同名包，或者您可能正在尝试发布已修补的版本，或者您可能正在尝试直接发布外部已经存在的确切软件包版本。 CodeCatalyst 拒绝您尝试发布的版本，但如有必要，您可以明确覆盖拒绝并发布该版本。

在下图中，RepoA 是您的 CodeCatalyst 软件包存储库，与存储库有上游连接。npm-public-registry-gateway您的软件包存储库包含从公共存储库中提取的 3.0 版本。您想将 1.2 版本发布到您的软件包存储库。通常，您可以将版本 1.2 发布到 RepoA，但是由于发布设置为 “阻止”，因此无法发布 1.2 版。

发布现有外部程序包的已修补程序包版本

在这种情况下，包名为 packageB 的外部存在于您已连接到软件包存储库的公共存储库中。当连接到您的存储库的程序包管理器请求 packageB 时，从公有存储库中将程序包版本摄取到您的存储库中。由于这是添加到存储库中的 P ackageB 的第一个软件包版本，因此软件包来源设置配置为 “发布:” BLOCK 和 “上游:ALLOW”。您的团队决定将此软件包的修补程序包版本发布到存储库。为了能够直接发布包版本，您的团队将包源控制设置更改为 “发布:” ALLOW 和 “上游:” BLOCK。此程序包的版本现在可以直接发布到您的存储库并从公有存储库中摄取。在您的团队发布已修补的软件包版本后，您的团队会将软件包来源设置恢复为 “发布:” BLOCK 和 “上游:”。ALLOW

编辑程序包来源控制

Package Origin 控制是根据将软件包的第一个软件包版本添加到包存储库中的方式自动配置的。有关更多信息，请参阅 默认程序包来源控制设置。要在包存储库中为包添加或编辑 CodeCatalyst 包源控件，请执行以下过程中的步骤。

添加或编辑包裹来源控制

1. 在导航窗格中，选择 Packages (程序包)。

2. 选择包含要编辑的软件包的软件包存储库。

3. 在 “包” 表格中，搜索并选择要编辑的软件包。

4. 在包摘要页面中，选择 Origin 控件。

5. 在 Origin 控件中，选择要为此包设置的包裹来源控制。必须同时设置两个包源控制设置，即 “发布” 和 “上游”。

   • 要允许直接发布程序包版本，请在发布中选择允许。要阻止发布程序包版本，请选择阻止。

   • 要允许从外部存储库摄取程序包和从上游存储库提取程序包，请在上游来源中选择允许。要阻止所有从外部存储库和上游存储库进行的程序包版本摄取和提取，请选择阻止。

6. 选择保存。

发布和上游存储库

在中 CodeCatalyst，您无法发布存在于可访问的上游存储库或公共存储库中的软件包版本。例如，假设你想将 npm 包lodash@1.0发布到存储库myrepo，并且myrepo有一个与 npmjs.com 有外部连接的上游存储库。考虑以下场景。

1. 上的软件包来源控制设置lodash为 “发布:” ALLOW 和 “上游:” ALLOW。如果存在lodash@1.0于上游存储库或 npmjs.com 中，则myrepo通过发出 CodeCatalyst 409 冲突错误来拒绝任何向其发布的尝试。您仍然可以发布另一个版本，例如 lodash@1.1。

2. 上的软件包来源控制设置lodash为 “发布:” ALLOW 和 “上游:” BLOCK。由于无法访问软件包版本，您可以lodash将任何尚不存在的版本发布到存储库中。

3. 上的软件包来源控制设置lodash为 “发布:” BLOCK 和 “上游:” ALLOW。您不能直接将任何程序包版本发布到您的存储库。

依赖项替换攻击

程序包管理器简化了打包和共享可重用代码的过程。这些程序包可能是组织为了在其应用程序中使用而开发的私有程序包，也可能是公有程序包（通常是在组织外部开发并由公有程序包存储库分发的开源程序包）。在请求程序包时，开发人员依靠他们的程序包管理器来提取其依赖项的新版本。依赖项替换攻击也称为依赖项混淆攻击，该攻击利用了这样一个事实，即程序包管理器通常无法区分程序包的合法版本和恶意版本。

依赖替换攻击属于被称为软件供应链攻击的攻击子集。软件供应链攻击是一种利用软件供应链中任何地方的漏洞进行的攻击。

依赖项替换攻击可以针对任何人，包括使用内部开发的程序包和从公有存储库提取的程序包的用户。攻击者识别内部程序包名称，然后策略性地将同名的恶意代码放置在公有程序包存储库中。通常，恶意代码在版本号较高的程序包中发布。因为程序包管理器认为恶意程序包是程序包的最新版本，所以从这些公有源中提取恶意代码。这会导致所需软件包和恶意软件包之间 “混淆” 或 “替换”，从而导致代码遭到破坏。

为了防止依赖替换攻击，Amazon CodeCatalyst 提供了包裹来源控制。程序包来源控制是用于控制如何将程序包添加到存储库的设置。将新软件包的第一个软件包版本添加到 CodeCatalyst 存储库时，会自动配置控件。这些控件可以确保软件包版本不能既直接发布到您的存储库，也不能从公共来源获取，从而保护您免受依赖关系替换攻击。有关程序包来源控制以及如何更改该设置的更多信息，请参阅编辑程序包来源控制。