DevSecOps 成熟度模型 2024

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义的构建过程已经将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来完成。风险：在没有定义流程的情况下进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。固定工件版本可以确保只有在预期时才进行更改。风险：未经授权的工件操作可能难以发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动应用于使用的图像，可能会破坏功能。SBOM（软件清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 的 workflow 文件夹中的一个可行配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 结合使用。为了增强安全性，建议考虑使用您的组织为特定仓库提供的细粒度个人访问令牌。在项目中将个人访问令牌（PAT）存储为秘密。风险：可能执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。标准：展示您的构建管道和示例工作（构建 测试）。| 显示每个团队成员都有访问权限。| 显示已修复的失败任务。鸣谢：AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/)

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义好的构建过程会将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来完成。风险：在没有定义流程的情况下进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。固定工件版本可以确保更改仅在预期情况下进行。风险：未经授权的工件操作可能难以发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动用于图像中，也可能破坏功能。SBOM（软件物料清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 工作流文件夹中的一个可用配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 结合使用。为了增强安全性，请考虑使用您的组织为特定存储库提供的细粒度个人访问令牌（PAT）。将个人访问令牌（PAT）作为机密存储在您的项目中。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。标准：在构建和测试阶段的每个步骤都在独立的虚拟环境中进行，之后该环境会被销毁。

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义的构建过程已经将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来完成。风险：在没有定义流程的情况下进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。固定工件版本可以确保只有在预期时才进行更改。风险：未经授权的工件操作可能难以发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动用于图像中，也可能破坏功能。SBOM（软件物料清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 的 workflow 文件夹中的一个可用配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 结合使用。为了增强安全性，请考虑使用您的组织为特定存储库提供的细粒度个人访问令牌（PAT）。将个人访问令牌（PAT）作为机密存储在您的项目中。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义好的构建过程会将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来完成。风险：在没有定义流程的情况下进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。工件固定可以确保更改仅在预期时进行。风险：工件的未授权操作可能很难被发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动用于图像中，也可能破坏功能。SBOM（软件物料清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 的 workflow 文件夹中的一个可用配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 一起使用。为了增强安全性，请考虑使用您的组织为特定存储库提供的细粒度个人访问令牌。在项目中将个人访问令牌（PAT）存储为机密。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。标准：在构建过程中创建组件的SBOM（例如应用程序和容器镜像内容）。

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义的构建过程已经将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来完成。风险：在没有定义流程的情况下进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。固定工件版本可以确保只有在预期时才进行更改。风险：未经授权的工件操作可能难以发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动用于图像中，也可能破坏功能。SBOM（软件物料清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 的 workflow 文件夹中的一个可用配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 结合使用。为了增强安全性，请考虑使用您的组织为特定存储库提供的细粒度个人访问令牌（PAT）。将个人访问令牌（PAT）作为机密存储在您的项目中。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。标准：对提交进行数字签名有助于防止未经授权的源代码篡改。

构建过程不仅仅包括编译源代码，还包括管理（第三方）依赖、环境配置、运行单元测试等步骤。定义明确的构建流程可以将这些步骤自动化，以确保一致性。这可以通过 Jenkinsfile、Maven 或类似工具来实现。风险：没有定义流程进行构建容易出错；例如，由于安全相关配置不正确的结果。在构建和测试工件时，会使用第三方系统、应用程序框架和第三方库。这些可能由于库的漏洞或在交付阶段被篡改而具有恶意性。风险：在构建和测试工件时，会使用第三方系统、应用框架和第三方库。这些可能因为库存在漏洞或在交付阶段被篡改而具有恶意性。工件固定可以确保更改仅在预期时进行。风险：工件的未授权操作可能很难被发现。例如，这可能导致使用带有恶意代码的图像。此外，预期的重大更改，自动用于图像中，也可能破坏功能。SBOM（软件物料清单）是一份列出软件应用程序或容器镜像中使用的所有组件、库和依赖项的文档。在构建过程中创建 SBOM 可以帮助确保应用程序的透明性、安全性和许可证合规性。风险：如果存在高或关键严重性的漏洞，需要知道带有该漏洞的制品部署在哪些依赖项中。对提交进行数字签名有助于防止未经授权的源代码篡改。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。要向 GitHub 仓库进行推送，您必须经过身份验证。需要注意的是，GitHub 不会验证经过身份验证的用户的电子邮件地址是否与提交中的地址匹配。为了让审阅者清楚地识别提交的作者，建议对提交进行签名。GitHub 操作，例如 semantic-release-action，并不会自动签署提交，因此可能会遇到问题。为了解决这个问题，您可以参考 DSOMM 的 workflow 文件夹中的一个可用配置示例，该示例演示了如何将 semantic release 操作与 planetscale/ghcommit-action 结合使用。为了增强安全性，请考虑使用您的组织为特定存储库提供的细粒度个人访问令牌（PAT）。将个人访问令牌（PAT）存储为项目中的机密。风险：执行或使用恶意代码或数据，例如通过可执行文件、库或容器镜像。标准：在构建的所有步骤中，尤其是 Docker 镜像上进行数字签名，有助于确保它们的完整性和真实性。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且产物符合这些标准。风险：部署不安全或功能异常的产物。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果从“生产制品清单”实施，也同样适用。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量来设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或工件（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署的位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**的风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝绿部署策略可以通过简化回滚流程来提高应用程序的可用性并降低部署风险，以防部署失败。风险：新版本的工件可能存在未知缺陷。标准：定义部署流程可以确保在功能、安全性、合规性和性能方面有已建立的标准，并且工件符合这些标准。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，依赖跟踪。风险：组织不了解生产环境中的组件，如应用程序。不知道生产环境中已有的应用程序会导致无法进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或秘密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未经授权访问存储在源代码或制品（例如容器镜像）中的秘密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署的位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。执行无需停机的部署*。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚流程来降低部署风险，以防部署失败。风险：新工件的版本可能存在未知缺陷。标准：存在生产环境中组件的文档化清单（手动或自动收集）。例如，一份手动创建的生产环境应用程序文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如存储在 S3 桶/Git 仓库中的 JSON 文件，或在依赖跟踪中。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量来设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或工件（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署的位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**的风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚过程在部署失败时降低部署风险。风险：新版本的工件可能存在未知的缺陷。标准：明确的退役流程确保删除未使用的应用程序。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果从“生产制品清单”实施，也同样适用。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中制品（如容器镜像）的清单（可手动或自动收集）。风险：如果存在高或严重漏洞，需要知道带有该漏洞的制品（例如容器镜像）部署在哪里。加密确保凭证的机密性，例如防止文件系统上的未经授权访问。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。已有记录的依赖清单存在于容器镜像和容器等工件中。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚流程在部署失败时降低部署风险。风险：新构件的版本可能存在未知缺陷。标准：通过特定平台功能或秘密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果从“生产制品清单”实施，也同样适用。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚流程在部署失败时降低部署风险。风险：新版本的工件可能存在未知缺陷。标准：评估每个组件的来源以确保可信。例如，源代码、所包括的开发者数量、维护者用来防止维护者账户被盗用的邮箱配置、错字仿冒等……创建镜像评估标准，对镜像进行评估，并创建工件/容器镜像/虚拟机镜像的白名单。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果从“生产制品清单”实施，也同样适用。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署的位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以通过简化回滚流程来提高应用程序的可用性并降低部署风险，如果部署失败，可以快速回退。风险：新版本的工件可能存在未知缺陷。标准：加密确保凭证的机密性，例如防止文件系统上的未经授权访问。此外，使用凭证管理系统可以帮助保护凭证。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且产物符合这些标准。风险：部署不安全或功能异常的产物。生产环境中的组件有记录在案的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件（如应用程序）。不了解生产环境中现有的应用程序会导致无法进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中制品（如容器镜像）的清单（可手动或自动收集）。风险：如果存在高或严重漏洞，需要知道带有该漏洞的制品（例如容器镜像）部署在哪里。加密确保凭证的机密性，例如防止文件系统上的未经授权访问。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝绿部署策略可以提高应用程序的可用性，并通过简化回滚流程来降低部署失败时的风险。风险：新工件的版本可能存在未知缺陷。标准：存在一份关于镜像和容器中使用的依赖项的文档化清单。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且制品符合这些标准。风险：部署不安全或功能异常的制品。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件，例如应用程序。不了解生产环境中存在的应用程序会导致无法对其进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的文档清单（可以手动或自动收集）。风险：如果存在高危或严重的漏洞，则需要知道具有该漏洞的工件（例如容器镜像）部署的位置。加密可确保凭证的机密性，例如防止未经授权的文件系统访问。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**的风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚流程在部署失败时降低部署风险。风险：新的工件版本可能存在未知缺陷。标准：执行无停机的部署。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且产物符合这些标准。风险：部署不安全或功能异常的产物。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件（如应用程序）。不了解生产环境中现有的应用程序会导致无法进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的文档化清单（手动或自动收集）。风险：如果存在高危或严重的漏洞，则需要知道具有该漏洞的工件（例如容器镜像）部署的位置。加密可确保凭证的机密性，例如防止未经授权的文件系统访问。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以通过简化回滚流程来提高应用程序的可用性并减少部署风险，如果部署失败，可以快速回滚。风险：新构建的版本可能存在未知缺陷。标准：只构建一次的工件并部署到不同环境意味着只有经过测试的工件才能进入生产环境。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且产物符合这些标准。风险：部署不安全或功能异常的产物。生产环境中的组件有记录在案的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，或依赖跟踪。风险：组织未意识到生产环境中的组件（如应用程序）。不了解生产环境中现有的应用程序会导致无法进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果实施，还可从“生产工件清单”中移除。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或机密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未授权访问存储在源代码或制品（例如容器镜像）中的机密。已经存在一个记录在生产中使用的工件（如容器镜像）的清单（手动或自动收集）。风险：如果存在高或严重等级的漏洞，需要知道该漏洞所在的工件（例如容器镜像）部署的位置。加密确保凭证的机密性，例如防止未授权访问文件系统。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**的风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝绿部署策略可以提高应用程序的可用性，并通过简化回滚过程来降低部署风险，如果部署失败。风险：新版本的构件可能存在未知缺陷。标准：使用环境独立的配置参数，即静态功能开关，可以降低在生产中意外启用不安全功能的风险。

定义部署流程可以确保在功能、安全性、合规性和性能方面有既定的标准，并且产物符合这些标准。风险：部署不安全或功能异常的产物。生产环境中的组件有一个已记录的清单（可以手动或自动收集）。例如，通过手动创建的包含生产环境中应用程序的文档。在 Kubernetes 集群中，命名空间可以被自动收集和记录，例如，在 S3 存储桶/ Git 仓库中的 JSON 文件，依赖跟踪。风险：组织不了解生产环境中的组件，如应用程序。不知道生产环境中已有的应用程序会导致无法进行评估。一个明确的退役流程可确保将未使用的应用程序从“生产组件清单”中移除，如果从“生产制品清单”实施，也同样适用。风险：未使用的应用程序无法得到维护，可能存在漏洞。一旦被利用，它们可能被用来攻击其他应用程序或在组织内部进行横向移动。通过使用特定平台功能或秘密管理系统（例如 Kubernetes secrets 或 Hashicorp Vault）存储的环境变量设置配置参数。风险：通过进程列表（例如 ps -ef）未经授权访问存储在源代码或制品（例如容器镜像）中的秘密。已经存在一个记录在生产中使用的工件（如容器镜像）的文档清单（可以手动或自动收集）。风险：如果存在高危或严重的漏洞，则需要知道具有该漏洞的工件（例如容器镜像）部署的位置。加密可确保凭证的机密性，例如防止未经授权的文件系统访问。此外，使用凭证管理系统可以帮助保护凭证。风险：参数通常用于设置凭证，例如通过启动容器或应用程序；这些参数通常可以被任何列出目标系统上运行进程的人看到。存在用于记录工件（如容器镜像和容器）中使用的依赖项的文档化清单。风险：在生产环境中延迟识别组件及其漏洞。如果组织已知某个漏洞，则需要知道带有该漏洞的制品部署在何处，以及其依赖关系。**执行无停机部署**。风险：在进行部署时，应用程序无法访问。一次构建工件并将其部署到不同环境意味着只有经过测试的工件才能进入生产环境。风险：为不同环境构建工件意味着未经测试的工件可能会进入生产环境。使用环境独立的配置参数，称为静态功能开关，可以降低在生产环境中意外启用不安全功能的风险。风险：使用环境变量来启用或禁用功能可能导致功能在生产环境中被意外启用的情况。使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚过程来降低部署风险，以防部署失败。风险：新版本的工件可能存在未知缺陷。标准：使用蓝/绿部署策略可以提高应用程序的可用性，并通过简化回滚过程来降低部署风险，以防部署失败。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速为第三方组件打补丁。DevOps 的方式是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要高自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件漏洞可能存在太久，并可能被利用。基础镜像是预构建镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能会被利用。标准：已为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器存在潜在的内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖自动创建的 PR 进行自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能被利用。标准：需要快速修补第三方组件。DevOps 的方式是为新组件创建自动拉取请求。这包括 *应用程序* 虚拟化操作系统组件（例如容器镜像）*操作系统* 基础设施即代码/GitOps（例如基于 Git 仓库的 ArgoCD 或 Terraform）

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。Distroless 镜像是最小化、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未到达持久层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能会被利用。标准：一个好的做法是在宽限期（例如一周）之后合并可信赖的依赖（例如 Spring Boot）。通常，补丁、修复和小版本更新会被自动合并。请注意，自动合并需要高覆盖率的自动化测试。在宽限期之后强制合并拉取请求。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在较长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的精简基础镜像，仅包含运行应用程序所需的基本组件。它们不包括包管理器、shell 或其他通常在标准 Linux 发行版中存在的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行中的容器中的漏洞存在时间过长，可能会被利用。标准：自定义基础镜像至少每晚构建一次。如果基础镜像中的软件包（例如 *centos*）发生变化，构建服务器会触发依赖镜像的构建。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在较长时间，并可能被利用。需要快速为第三方组件打补丁。DevOps 的方式是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：运行中的容器漏洞存在时间过长，可能被利用。标准：删除不需要的组件、依赖项、文件或文件访问权限。对于容器镜像，建议使用无发行版（distroless）镜像。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能被利用。标准：定义了镜像的最大使用寿命，例如 30 天。基于每晚构建的镜像的项目镜像，在定义的使用寿命内至少部署一次。第三方镜像在定义的使用寿命内至少部署一次。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未达到持久化层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像及第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能会被利用。标准：在合并自动化依赖 PR 后，需要进行自动部署。

为所有制品（例如镜像）定义了补丁策略。镜像多久重建一次？风险：正在运行的制品中的漏洞可能存在很长时间，并可能被利用。需要快速修补第三方组件。DevOps 的做法是为新组件创建自动拉取请求。这包括 * 应用程序 * 虚拟化操作系统组件（例如容器镜像）* 操作系统 * 基础设施即代码/GitOps（例如基于Git仓库的Argo CD或Terraform）。风险：具有已知（或未知）漏洞的组件可能会长时间存在并被利用，即使补丁已可用。对过时依赖项自动创建的PR进行自动合并。一个好的做法是在经过像一周这样的宽限期后，再合并可信赖的依赖项（例如Spring Boot）。通常，补丁、修复和小更新会自动合并。请注意，自动合并需要较高的自动化测试覆盖率。在宽限期后强制合并拉取请求。风险：运行中的工件中的漏洞存在时间过长，可能被利用。基础镜像是一个预构建的镜像，用作构建新镜像或容器的起点。这些基础镜像通常包括操作系统、必要的依赖项、库以及运行特定应用程序或服务所需的其他组件。自定义基础镜像的夜间构建是指一个自动化过程，该过程每天或按计划进行，通常在夜间或非高峰时段，用于创建自定义基础镜像的更新版本。风险：运行中的容器中的漏洞存在时间过长，可能被利用。无发行版镜像是最小化的、精简的基础镜像，仅包含运行您的应用所需的必要组件。它们不包括包管理器、shell 或其他常见于标准 Linux 发行版的工具。使用无发行版镜像可以帮助减少攻击面和容器镜像的总体大小。风险：组件、依赖项、文件或文件访问权限可能存在漏洞，但其实并不需要。Docker 容器的最大生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：运行容器的镜像中的漏洞存在时间过长，可能被利用。长时间运行的容器可能存在内存泄漏。受损的容器可能通过重启容器被终止（例如，如果攻击者尚未到达持久层）。对过时依赖项自动创建的 PR 的自动合并。风险：即使自动化依赖的 PR 被合并，它们也可能未被部署。这会导致运行中的工件存在漏洞的时间过长，并可能被利用。Docker 容器的最长生命周期是指容器在被认为过时、陈旧或不安全之前允许运行的时间。Docker 容器没有固定的、普遍适用的最大生命周期，这取决于具体的使用案例、应用需求和安全需求。作为最佳实践，必须为容器定义一个合理的最大生命周期，以确保你始终部署最新的、已修补和安全的自定义基础镜像和第三方镜像版本。风险：正在运行的容器中的漏洞存在时间过长，可能会被利用。标准：一个好的做法是每天甚至在新组件（例如软件包）可用于镜像时及时进行构建和部署。