新闻动态

风险管理的实践与思考

发布时间：

2024-08-09 18:56

随着软件开发实践的不断演进，DevSecOps 的重要性愈发突出。在过去，风险管理主要集中于开发后期或生产阶段，但如今，随着容器化、基础设施即代码 (IaC)、AI 编码助手以及对第三方代码的依赖日益增加，安全团队必须在现有工作流程中不断适应并满足开发人员的需求。本文将探讨这些新兴实践对风险管理的影响，并提供一些应对策略。

一：新技术带来的新风险面

容器化：新的安全边界

容器化技术的广泛应用改变了应用程序的部署方式。容器能够确保应用程序在不同环境中的一致性，但同时也引入了新的安全挑战。容器镜像中可能包含未修补的风险或恶意代码，尤其是在使用来自公共镜像库的镜像时。为了应对这一挑战，安全团队必须在整个开发周期中引入持续的容器安全扫描和监控。自动化工具可以帮助识别容器中的已知风险，并在容器部署前进行修复。此外，容器编排工具（如 Kubernetes）本身也需要严格的安全配置，以防止潜在的攻击。

基础设施即代码 (IaC)：自动化带来的新风险

基础设施即代码 (IaC) 的兴起使得基础设施管理和部署变得更加自动化和高效。通过将基础设施配置代码化并纳入版本控制，IaC 极大地简化了基础设施的管理。然而，这种做法也引入了新的风险：如果 IaC 文件中存在不安全配置或错误，可能会在生产环境中引入风险。为了解决这个问题，安全团队应在开发阶段引入自动化工具，对 IaC 文件进行安全扫描。工具可以检测出潜在的配置问题，并在部署之前进行修复。此外，定期审查 IaC 文件并确保其符合最新的安全标准也是关键。

第三方代码：依赖的安全风险

现代开发中，第三方库和开源代码的使用已成为常态。虽然这些资源可以加快开发进程，但它们也可能引入未经过全面审查的安全风险或恶意代码。特别是在依赖关系复杂的项目中，管理这些依赖项变得尤为重要。安全团队应建立一个严格的第三方代码管理流程，确保所有引入的库和工具都经过安全审查。定期更新依赖项并监控其安全性是防止风险利用的关键。此外，企业可以考虑使用制品安全平台，对第三方组件进行持续的安全扫描和管理，确保开发过程中的每一个环节都符合安全标准。

AI 编码助手：效率与安全的平衡

AI 编码助手（如 GitHub Copilot）的出现大大提高了开发人员的生产力，但它们也可能引入不安全的代码片段。这些工具有时会建议使用包含已知风险的代码模式，或生成不符合安全最佳实践的代码。为了在提高效率的同时保持代码的安全性，开发人员需要对 AI 生成的代码进行仔细审查。安全团队可以提供培训和工具，帮助开发人员识别和修复潜在的安全问题。此外，引入自动化的代码审查工具也是一个有效的措施，确保 AI 生成的代码在合并之前经过安全检查。

二：传统风险管理的局限性及应对措施

孤立处理风险

问题传统风险管理往往将每个风险看作是独立存在的，忽略了它们之间可能的相互作用。修复一个风险可能会引发代码其他部分的问题，导致新的风险。

应对措施整体风险评估: 在处理风险时，团队应采用系统思维，考虑整个应用程序环境的影响。每次更改代码时，应该进行全面的回归测试，以确保修复不会引入新的问题。自动化工具: 使用自动化工具来模拟代码更改的潜在影响，识别出可能的新风险区域。

过度依赖标准评分系统

问题 CVSS等标准评分系统虽然有助于量化风险，但它们未考虑业务背景和漏洞所在的具体环境。修复工作有时可能并不完全依据评分高低，而是应根据漏洞对业务的实际影响来优先处理。

应对措施风险优先级调整: 根据业务关键性来调整风险优先级，确保团队能够集中精力修复对业务影响最大的漏洞，而不仅仅是依据CVSS评分。上下文感知分析: 增加对漏洞所在环境的分析，结合业务逻辑和应用程序的重要性，制定更为精准的修复计划。

上下文切换和外部工具使用

问题开发人员需要在开发过程的早期阶段离开他们的工作环境，去使用单独的安全工具，这种上下文切换会导致效率低下。

应对措施集成工具链: 将安全扫描和漏洞修复功能集成到开发人员日常使用的开发环境中，如IDE和CI/CD管道中，减少上下文切换，提供实时的漏洞检测和修复建议。持续集成与持续交付（CI/CD）: 实施CI/CD流程，让安全测试成为开发过程的一部分，减少独立测试平台的需求。

单一视图整合的挑战

问题试图将所有漏洞整合到一个视图中是困难的，尤其是在大型、复杂的开发环境中，这种方法可能会导致信息过载，并使得真正关键的漏洞被忽视。

应对措施分层风险管理: 实施分层的风险管理策略，首先关注业务关键型应用和高风险领域，然后逐步扩展覆盖范围。智能筛选: 利用智能分析工具筛选出最重要的漏洞，并根据实际业务需求和开发环境的复杂性进行调整。这些应对措施可以帮助团队更好地管理和修复风险，而不是依赖于传统的、可能已经过时的风险管理和漏洞管理方法。我们需要遵循上下文、基于风险和开发人员优先的方法，直接解决了传统风险管理的局限性。为企业提供资产优先的方法，根据业务重要性而不是通用 CVSS 对其最关键资产进行优先排序。

三：8590am发现海洋之神云原生安全防护解决方案

8590am发现海洋之神科技基于云原生安全理念，为云原生的全生命提供全面的安全防护解决方案。

支持对容器及集群进行合规审计，支持主流的CIS安全检测标准，包括Docker CIS、Kubernetes CIS合规、Centos CIS、Ubuntu CIS、OpenShift合规等多种系统合规项检测，并支持快速扩展，满足不同场景的需求。

支持对于部署资源所编写的编排文件，系统支持自动接入，自动扫描，根据扫描结果指出编排文件中存在风险或不规范的配置项，并给出修复建议，保障资源合规且安全的创建。

支持对容器镜像制作过程、镜像运行、镜像发布进行全方位的监控与检测。提供了自动获取节点和仓库中的镜像并从CVE漏洞、CNNVD漏洞、木马病毒、可疑历史操作、敏感信息泄露、以及是否是可信任镜像等多个维度对镜像进行扫描。

支持对容器内行为进行检测。当发现容器逃逸行为、读取敏感信息、启动恶意进程、挂载非法设备、映射敏感目录、修改命名空间等恶意行为时，根据预设策略触发报警或阻断容器运行，并对发现异常的POD进行隔离。

对微服务、应用进行周期性的检测，多种安全漏洞，包括XSS漏洞、SQL注入、命令/代码注入等。管理员可以通过全面的安全扫描，发现并解决微服务中可能存在的各类威胁。通过深度学习和规则引擎，检测并拦截恶意的HTTP/HTTPS请求，防范常见的Web攻击，如SQL注入、XSS攻击、CSRF攻击等。

支持对节点检测节点操作系统中的已知漏洞（例如未修补的CVE）与恶意软文件，并提供修复建议。监控系统行为，检测潜在的入侵迹象，例如异常的网络流量、系统资源使用情况、未经授权的文件修改等。

支持对Kubernetes、OpenShift 、Rancher等集群的不同版本进行安全风险扫描。如：Kubernetes版本信息披露、匿名身份验证、可能遭受Ping Flood 攻击等。

8590am发现海洋之神科技从上述风险的识别、分类、修复和缓解风险管理实践过程中进行思考总结：在整个应用生命周期中识别风险。对已发现的风险进行分类和分析，以了解其性质、严重性和潜在影响。通过应用补丁、更改配置或实施变通控制来修复和减轻已发现的风险。报告并记录所有风险管理流程和结果。持续监控和审查组织的应用以适应新的威胁。