机密扫描

工程系统中公开的凭据为攻击者提供了易于利用的机会。 为了抵御此威胁，适用于 Azure DevOps 的 GitHub Advanced Security 会扫描源代码中的凭据和其他敏感内容。 推送保护还可以从一开始就防止任何凭据被泄露。

存储库的机密扫描跨历史记录扫描源代码中可能已存在的任何机密，并且推送保护防止在源代码中公开任何新机密。

适用于 Azure DevOps 的 GitHub Advanced Security 可与 Azure Repos 配合使用。 如果要将 GitHub Advanced Security 与 GitHub 存储库配合使用，请参阅 GitHub Advanced Security。

关于机密扫描警报

启用 Advanced Security 后，它会扫描存储库中由各种服务提供商颁发的机密，并生成机密扫描警报。

如果访问资源需要配对的凭据，则只有在同一文件中检测到该配对的两个凭据时，机密扫描才可创建警报。 配对可确保最关键的泄露不会隐藏在有关部分泄露的信息后面。 配对还有助于减少误报，因为一个配对的两个元素必须一起使用才能访问提供商的资源。

Azure DevOps 中位于 Repos>Advanced Security 的“Advanced Security”选项卡是查看安全警报的中心。 选择密钥选项卡以查看密钥扫描警报。 可以按状态和机密类型进行筛选。 可以导航到警报以获取更多详细信息，包括修正指南。 启用 Advanced Security 后，将开始对所选存储库（包括所有历史提交）进行扫描。 经过一段时间，随着扫描的进行，警报将开始显示。

重命名分支不会对结果产生影响 - 最多可能需要 24 小时才能显示新名称。

若要修正公开的机密，请使公开的凭据失效，并在其位置创建一个新凭据。 然后，新创建的机密应该以一种不会直接将其推送回代码中的方式安全地存储。 例如，机密可以存储在 Azure Key Vault 中。 大多数资源同时具有主要凭据和辅助凭据。 除非另有说明，否则滚动更新主要凭据与辅助凭据的方法是相同的。

管理机密扫描警报

查看存储库的警报

任何拥有存储库参与者权限的人都可以在“Repos”下的“Advanced Security”中查看存储库所有警报的摘要。 选择密钥选项卡以查看所有密钥扫描警报。

如果最近为存储库启用了 Advanced Security，你可能会看到一个卡，指示 Advanced Security 仍在扫描存储库。

扫描完成后，将显示任何结果。 针对存储库的所有分支和历史记录中检测到的每个唯一凭据生成单个警报。 没有分支筛选器，因为它们汇总到一个警报中。

可通过从“密钥扫描”选项卡上的“置信度”下拉列表选择“其他”来查看非提供程序密钥。

警报详细信息

导航到警报时，将显示详细的警报视图，其中显示有关查找结果的更多详细信息，并提供解决警报的特定修正指南。

部分	说明
位置	位置部分详细说明了密钥扫描发现泄露的凭据的路径。 历史记录中可能有多个位置或多个提交包含泄露的凭据。 所有这些位置和提交都显示在位置下，其中包含一个直接链接，指向代码片段及在其中标识了该代码片段的提交。
建议	“建议”部分包含已标识凭据的修正指南或指向第三方文档修正指南的链接。
关闭警报	对于机密扫描警报，没有自动修复行为。 所有机密扫描警报都必须通过“警报详细信息”页手动证明为已修复。 选择关闭按钮以验证密钥是否已撤销。
Severity	所有机密扫描警报都设置为“关键”。 任何公开的凭据都有可能成为恶意参与者的机会。
查找详细信息	凭据类型和用于查找凭据的规则列在“警报详细信息”页边栏的查找详细信息下。

使用非提供程序密钥时，置信度:其他标记也会通过警报详细信息视图中的严重性锁屏提醒来显示。

修复机密扫描警报

每个机密都有独特的修正步骤，指导你如何在其位置撤消和重新生成新机密。 “警报详细信息”共享每个警报的特定步骤或文档。

机密扫描警报一直处于打开状态，直到关闭。 若要证明已修复机密扫描警报，请执行以下操作：

1. 导航到要关闭的警报并选择该警报。
2. 选择关闭警报下拉列表。
3. 如果尚未选择，请选择已修复。
4. 选择关闭以提交并关闭警报。

消除机密扫描警报

若要消除 Advanced Security 中的警报，你需要适当的权限。 默认情况下，只有项目管理员可以消除 Advanced Security 警报。 有关 Advanced Security 权限的详细信息，请参阅管理 Advanced Security 权限。

消除警报：

1. 导航到要关闭的警报并选择该警报。
2. 选择“关闭警报”下拉列表。
3. 请选择“接受的风险”或“误报”作为关闭原因（如果尚未选择）。
4. 在“注释”文本框中添加可选注释。
5. 选择关闭以提交并关闭警报。
6. 警报状态从打开更改为已关闭并显示消除原因。

之前已消除的任何警报都可以手动重新打开。

保护受到威胁的密码

一旦机密被提交到存储库，机密就会被泄露。 Microsoft 建议对已泄露的机密采取以下措施：

• 对于已泄露的 Azure DevOps 个人访问令牌，请删除已泄露的令牌，创建新令牌，并更新使用旧令牌的所有服务。
• 对于所有其他机密，首先验证提交给 Azure Repos 的机密是否有效。 如果有效，请创建新机密，更新使用旧机密的所有服务，然后删除旧机密。
• 确认已泄露的令牌对企业资源采取的任何操作。

更新机密时，请务必安全地存储新机密，并确保该机密始终被访问，并且永远不会以纯文本形式存储。 一种选择是通过 Azure Key Vault 或其他机密管理解决方案来实现。

机密推送保护

推送保护会检查任何传入的推送是否具有高可信度的机密，并防止推送通过。 错误消息显示所有标识的机密，以便删除它们或根据需要继续推送机密。

关于推送保护警报

推送保护警报是推送保护报告的用户警报。 作为一种推送保护，机密扫描当前扫描存储库，查找部分服务提供商颁发的机密。

如果访问资源需要配对的凭据，则只有在同一文件中检测到该配对的两个凭据时，机密扫描才可创建警报。 配对可确保最关键的泄露不会隐藏在有关部分泄露的信息后面。 对匹配还有助于减少误报，因为对的两个元素必须一起使用才能访问提供商的资源。

推送保护可能不会阻止某些旧版令牌，因为这些令牌生成的误报数可能高于其最新版本。 推送保护也可能不会阻止旧令牌。 对于 Azure 存储密钥等令牌，Advanced Security 仅支持“最近创建”令牌，不支持与旧模式匹配的令牌。

命令行中的推送保护

推送保护原生内置于 Azure DevOps Git 中。 如果提交包含已标识的机密，则你会看到推送被拒绝的错误。

Web 界面中的推送保护

推送保护也可以在 Web 界面中工作。 如果在提交中标识了机密，则你会看到以下阻止推送更改的错误块：

推送被阻止时该怎么办

推送保护阻止在纯文本文件中发现的机密，这些文件通常是（但不限于）源代码或 JSON 配置文件等文本文件。 这些机密以纯文本形式存储。 如果恶意参与者获得了对文件的访问权限，并且这些文件被发布到公共存储库，则任何人都可使用这些机密。

建议从标记的文件中删除机密，然后从提交历史记录中删除机密。 如果标记的机密是一个占位符或示例机密，建议更新虚设机密以在虚设机密前面追加 Placeholder 字符串。

如果在最接近的上一个提交中添加了机密，请修改该提交并创建新提交：

1. 从代码中删除机密。
2. 使用 git commit --amend 提交更改
3. 再次推送更改。

如果在更早的历史记录中添加了机密，请使用交互式变基来编辑提交：

1. 使用 git log 确定首次提交机密的提交。
2. 执行交互式变基：git rebase -i [commit ID before credential introduction]~1
3. 通过将编辑器中显示的文本的第一行上的 pick 更改为 edit 来确定要编辑的提交。
4. 从代码中删除机密。
5. 使用 git commit --amend 提交更改。
6. 通过运行 git rebase --continue 以完成变基。

推送被阻止的机密

建议不要绕过已标记的机密，因为绕过可能会危及公司的安全。 如果确认已标识的机密不是误报，则应从整个分支历史记录中删除该机密，然后再尝试再次推送更改。

如果你认为阻止的机密是误报或可安全推送，则可以绕过推送保护。 在提交消息中包含 skip-secret-scanning:true 字符串。 即使绕过推送保护，推送机密后，也会在警报 UX 中生成机密扫描警报。