工程系统中公开的凭据为攻击者提供了易于利用的机会。 为了抵御此威胁，Azure DevOps 的 GitHub 高级安全性会扫描源代码中的凭据和其他敏感内容。 推送保护还可以从一开始就防止任何凭据被泄露。 需要启用适用于 Azure DevOps 的 GitHub 高级安全功能，或者，如果您使用的是独立版本，则需要启用适用于 Azure DevOps 的 GitHub 机密保护功能。
存储库的机密扫描会扫描历史记录中可能已经存在的任何机密，推送保护可防止任何新机密在源代码中公开。
适用于 Azure DevOps 的 GitHub Advanced Security 可与 Azure Repos 配合使用。 若要将 GitHub 高级安全性与 GitHub 存储库配合使用，请参阅 GitHub 高级安全性。
先决条件
| 类别 | 要求 |
|---|---|
| 权限 | - 若要查看存储库的所有警报的摘要：存储库的 参与者 权限。 - 若要消除高级安全性中的警报： 项目管理员 权限。 - 若要管理高级安全性中的权限：需要成为 项目集合管理员 组的成员，或者将 高级安全性：管理设置 权限设置为 允许。 |
有关高级安全权限的详细信息，请参阅 “管理高级安全”权限。
关于机密扫描警报
特别是启用高级安全或机密保护时，它会扫描存储库中是否存在各种服务提供商颁发的机密，并生成机密扫描警报。
如果访问资源需要配对凭据，则仅当在同一文件中检测到配对的两部分时，机密扫描才会创建警报。 配对可确保最关键的泄露不会隐藏在有关部分泄露的信息后面。 对匹配还有助于减少误报，因为对的两个元素必须一起使用才能访问提供商的资源。
Azure DevOps 中位于 Repos>Advanced Security 的“Advanced Security”选项卡是查看安全警报的中心。 选择密钥选项卡以查看密钥扫描警报。 可以按状态和机密类型进行筛选。 导航到警报以获取更多详细信息，包括修正指南。 启用高级安全性后，将启动所选存储库的扫描，包括所有历史提交。 经过一段时间，随着扫描的进行，警报将开始显示。
重命名分支不会影响结果。 但是，可能需要长达 24 小时才能显示新名称。
若要修正公开的机密，请使公开的凭据失效，并在其位置创建一个新凭据。 然后，新创建的机密应该以一种不会直接将其推送回代码中的方式安全地存储。 例如，机密可以存储在 Azure Key Vault 中。 大多数资源同时具有主要凭据和辅助凭据。 除非另有说明，否则滚动更新主要凭据与辅助凭据的方法是相同的。
管理机密扫描警报
查看存储库的警报
选择“ 机密 ”选项卡可查看所有机密扫描警报。
如果最近为存储库启用了高级安全性，你可能会看到一张卡，指示高级安全仍在扫描存储库。
扫描完成后，将显示任何结果。 针对存储库的所有分支和历史记录中检测到的每个唯一凭据生成单个警报。 没有分支筛选器，因为它们汇总到一个警报中。
可以通过从机密扫描选项卡上的置信度下拉列表中选择“其他”来查看非provider 机密。
警报详细信息
导航到警报时，将显示详细的警报视图，其中显示有关查找结果的更多详细信息，并提供解决警报的特定修正指南。
| 部分 | 说明 |
|---|---|
| 位置 | “ 位置” 部分详细介绍了机密扫描发现泄露凭据的路径。 历史记录中可能有多个位置或多个提交，其中包含泄露的凭据。 所有这些位置和提交都显示在位置下，其中包含一个直接链接，指向代码片段及在其中标识了该代码片段的提交。 |
| 建议 | 建议部分包含修正指南或指向非微软文档的标识凭据修正指南的链接。 |
| 关闭警报 | 对于机密扫描警报，没有自动修复行为。 所有机密扫描警报都必须通过“警报详细信息”页手动证明为已修复。 选择关闭按钮以验证密钥是否已撤销。 |
| 严重程度 | 所有机密扫描警报都设置为“关键”。 任何公开的凭据都有可能成为恶意参与者的机会。 |
| 查找详细信息 | 凭据类型和用于查找凭据的规则列在“警报详细信息”页边栏的查找详细信息下。 |
使用非提供商机密时，“置信度：”其他 标记也会出现在警报详细信息视图中的严重性徽章旁。
修复机密扫描警报
每个机密都有独特的修正步骤，指导你如何在其位置撤消和重新生成新机密。 “警报详细信息”共享每个警报的特定步骤或文档。
机密扫描警报一直处于打开状态，直到关闭。 若要证明已修复机密扫描警报，请执行以下操作：
- 导航到要关闭的警报并选择该警报。
- 选择关闭警报下拉列表。
- 如果尚未选择，请选择已修复。
- 选择关闭以提交并关闭警报。
消除机密扫描警报
若要消除警报，请执行以下步骤：
- 导航到要关闭的警报并选择该警报。
- 选择关闭警报下拉列表。
- 请选择“接受的风险”或“误报”作为关闭原因（如果尚未选择）。
- 在“注释”文本框中添加可选注释。
- 选择关闭以提交并关闭警报。
- 警报状态从打开更改为已关闭并显示消除原因。
可以手动打开以前关闭的任何警报。
确保泄露的机密安全
将机密提交到存储库后，机密将遭到入侵。 Microsoft 建议对已泄露的机密采取以下措施：
重要
我们建议使用更安全的Microsoft Entra 令牌，而不是高风险的个人访问令牌。 详细了解我们 减少 PAT 使用率的努力。 查看我们的 身份验证指南 ，以根据需要选择正确的身份验证机制。
- 对于已泄露的 Azure DevOps 个人访问令牌，请删除已泄露的令牌，创建新令牌，并更新使用旧令牌的所有服务。
- 对于所有其他机密，首先验证提交给 Azure Repos 的机密是否有效。 如果有效，请创建新机密，更新使用旧机密的所有服务，然后删除旧机密。
- 确认受入侵令牌对企业资源执行的任何操作。
更新机密时，安全地存储新机密，并确保它永远不会以纯文本形式存储。 一个选项是使用 Azure Key Vault 或其他机密管理解决方案。
机密推送保护
推送保护会检查任何传入的推送是否具有高可信度的机密，并防止推送通过。 错误消息显示所有标识的机密，以便删除它们或根据需要继续推送机密。
关于推送保护警报
推送保护警报是推送保护报告的用户警报。 作为一种推送保护，机密扫描当前扫描存储库，查找部分服务提供商颁发的机密。
如果访问资源需要配对凭据，则仅当在同一文件中检测到凭据对的两个部分时，秘密扫描才会创建警报。 配对可确保最关键的泄露不会隐藏在有关部分泄露的信息后面。 对匹配还有助于减少误报，因为对的两个元素必须一起使用才能访问提供商的资源。
推送保护可能不会阻止某些令牌的旧版本，因为这些令牌相比最新版本可能导致误报数量更高。 推送保护也可能不阻止传统令牌。 对于 Azure 存储密钥等令牌，Advanced Security 仅支持“最近创建”令牌，不支持与旧模式匹配的令牌。
命令行中的推送保护
推送保护原生内置于 Azure DevOps Git 中。 如果提交包含已识别的机密，则以下错误显示推送被拒绝。
Web 界面中的推送保护
推送保护也可以在 Web 界面中工作。 如果在提交记录中标识了机密，将显示以下错误信息块，从而阻止你推送更改：
推送被阻止时该怎么办
推送保护阻止在纯文本文件中发现的机密，这些文件通常是（但不限于）源代码或 JSON 配置文件等文本文件。 这些机密以纯文本形式存储。 如果恶意参与者获得了对文件的访问权限，并且这些文件被发布到公共存储库，则任何人都可使用这些机密。
从标记的文件中删除机密，然后从提交历史记录中删除机密。 如果标记的机密是占位符或示例机密，请更新假机密以在假机密前面追加字符串 Placeholder 。
如果在最接近的上一个提交中添加了机密，请修改该提交并创建新提交：
- 从代码中删除机密。
- 使用
git commit --amend提交更改 - 再次推送更改。
如果在更早的历史记录中添加了机密，请使用交互式变基来编辑提交：
- 使用
git log确定首次提交机密的提交。 - 执行交互式变基：
git rebase -i [commit ID before credential introduction]~1 - 通过将编辑器中显示的文本的第一行上的
pick更改为edit来确定要编辑的提交。 - 从代码中删除机密。
- 使用
git commit --amend提交更改。 - 通过运行
git rebase --continue以完成变基。
推送被阻止的机密
不要绕过已标记的机密，因为这样做可能会使公司的安全面临风险。 如果确认已识别的机密不是误报，请在尝试再次推送更改之前，从整个分支历史记录中删除机密。
如果你认为阻止的机密是误报或可安全推送，则可以绕过推送保护。 在提交消息中包含 skip-secret-scanning:true 字符串。 即使绕过了推送保护，一旦机密被推送，警报用户体验中也会生成机密扫描警报。