你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。

建议的代码到运行时扩充

新式云应用程序会经历可能包括源代码、管道、注册表和运行时环境的阶段。 小型代码更改可以在环境中创建多个云工作负载。 当运行时出现安全问题时,你可能不知道问题开始的位置或它影响的资产数。

代码到运行时为你提供了整个软件开发生命周期(SDLC)的端到端可视化。 代码到运行时帮助你找到问题的根源,评估其影响,并在源头修复问题。

在继续之前,请先了解一下 容器图像映射的前置条件。

在看到“代码到运行时”的地方

你可以通过 Microsoft Defender for Cloud 的推荐访问代码到运行时。

注释

目前仅支持容器和容器映像漏洞评估建议。

当 SDLC 上下文可用时,建议页将显示:

  • 显示问题 SDLC 流程的上下文横幅
  • SDLC 链视图:源→ CI/CD 管道→注册表→运行时
  • 受影响资产的动态计数
  • 表示每个 SDLC 阶段的卡片
  • 指向更深入视图和补救措施的链接

代码在运行时如何构建端到端上下文

对于任何支持代码到运行时的推荐,Defender 会跨 SDLC 关联数据以识别:

  • 问题的来源,比如代码或构建流水线。
  • 涉及哪些中间阶段。 这些阶段包括注册表中的镜像和部署过程中涉及的 CI/CD 管道。
  • 影响了多少资产,这样你才能看到影响。
  • 可在每个阶段执行的操作。

为什么此功能很重要

代码到运行时的重要性有多方面:

  • 如果你只在运行时修复问题,下一次部署时它可能会重新出现。
  • 从源头修复问题可以防止复发。
  • 了解影响有助于你规划推广和协调工作。
  • 这有助于你确定修复的主人。

沿 SDLC 链从运行时回溯到源头

SDLC 链提供了一个明确的线性路径,用于说明如何创建受影响的工作负荷。 每个阶段显示为卡片。 你可以展开每个关卡,查看元数据和可用动作。

了解问题的影响

采取行动前,请打开 所有受影响资产 网格了解更多信息:

  • 该列表显示来自同一源的受影响资产。 它包括云环境或代码环境中的资产。 修复源中的问题可能会通过自动化 CI/CD 过程或手动部署新代码来影响所有受影响的资产。
  • 根据你的偏好筛选列表。 例如,按Kubernetes命名空间过滤运行时资产,将问题分配给特定的开发团队。 你还可以按相关资源元数据筛选,比如图片标签和标签。
  • 选择一行时,系统会显示该问题实例的更多详细信息。

网格显示:

  • 同一安全问题和相同来源的每个受影响资源
  • 根据资源类型的不同元数据项
  • 筛选和导航选项

受影响资产网格可以帮助你:

  • 确定问题的优先级
  • 协调与负责团队的合作
  • 确定是否需要分阶段推出
  • 避免无意破坏依赖工作负载

处理缺失或部分数据

有些SDLC阶段可能无法显示完整数据。 常见原因包括:

  • 禁用的连接器
  • 缺少权限
  • 缺少管道信号
  • 不支持的设置

对于每个间隙,Defender 显示:

  • 数据缺失的原因
  • 如何启用或设置缺失的部分
  • 扩大SDLC覆盖的下一步

根据这些见解采取行动

在了解问题及其影响后,选择合适的下一步:

分配所有权

将建议直接分配给 Defender for Cloud 内部的人员或团队。

如果你启用仓库集成,你可以:

  • 使用 SDLC 上下文自动填充问题
  • 将其直接路由到相关的修复程序
  • 提供有关需要更改的内容的精确指导

了解更多关于GitHub高级安全与Microsoft Defender for Cloud的集成。

注释

该功能目前仅在 Azure 门户中提供。

申请豁免

以一致的方式应用豁免。

如果您暂时或永久豁免某项认定,您可以这样做:

  • 在最合适的 SDLC 阶段
  • 一次性,而不是在多个工作负载中重复
  • 如果您希望获得对特定结果的可视性,可以使用部分豁免。

示例工作流

典型使用代码到运行时的调查包括以下步骤:

  1. 打开一个容器推荐系统。
  2. 查看 SDLC 上下文横幅。
  3. 确定问题最早出现的阶段。
  4. 展开 SDLC 卡以浏览源、管道、注册表和运行时数据。
  5. 使用影响网格了解受影响的工作负荷数。
  6. 分配所有权或打开 GitHub 议题。
  7. (可选)在适当的软件开发生命周期阶段应用豁免。

总结

代码到运行时为您提供了软件开发生命周期(SDLC)中统一且具上下文的视图,从而您可以:

  • 查找运行时问题的真正来源
  • 了解其覆盖范围
  • 在最有效的位置修复一次
  • 为工程团队提供可操作的、精确的上下文

这种方法有助于安全和工程团队协同工作,减少重复的手动修复。