
Checkov 术语与核心概念解析Policy、Composite Policy、Incident、Resource 与 Suppression 实战指南【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkov本文基于 Checkov 官方《Terms and Concepts》术语表系统讲解 Checkov 安全扫描体系中的五大核心概念——Policy、Composite Policy、Incident、Resource 与 Suppression并结合仓库源码与真实检查定义文件解释这些概念在扫描流程中的底层实现与命令行用法。读完本文你将能准确理解 Checkov 的扫描结果、读懂 YAML 策略文件结构并掌握用 Suppression 和--skip-check管理误报与豁免的标准姿势。一、为什么先要理解这些术语Checkov 是一款在构建阶段对基础设施即代码IaC、容器镜像与开源软件包进行云配置错误扫描与漏洞发现的静态分析工具。理解它输出的每一行结果前提是掌握其内部对策略事件资源的定义方式。这些术语不仅是文档用语更直接映射到源码中的数据结构与执行逻辑例如checkov/common/output/record.py中的Record类、checkov/common/checks_infra/registry.py中的Registry类。下面先从五个核心概念讲起再补充常用术语最后给出源码级佐证与实战操作。二、Checkov 的五个核心概念1. Policy策略合规的判定标准Policy策略定义了云配置中影响环境整体安全性的各种方面。例如root 账户应启用多因素认证MFA。凡是不处于策略所定义状态下的资源即为不合规non-compliant并会出现在扫描结果中。在 Checkov 中策略有两种承载形态Python 类检查继承BaseCheck并实现scan_entity_conf等方法YAML/JSON 图检查graph check以声明式配置文件描述什么资源、满足什么条件即失败。以仓库中的真实检查为例checkov/cdk/checks/python/ALBListenerHTTPS.yaml 展示了标准策略文件结构metadata: version: 0.2 approach: define failing id: CKV_AWS_2 name: Ensure EFS is securely encrypted category: ENCRYPTION framework: cdk scope: languages: - python definition: pattern: aws_cdk.aws_elasticloadbalancingv2.CfnListener(ANY) conditions: - not_pattern: aws_cdk.aws_elasticloadbalancingv2.CfnListener(ANY, protocolHTTPS, ANY) - not_pattern: aws_cdk.aws_elasticloadbalancingv2.CfnListener(ANY, protocolTLS, ANY) # ... 其他协议豁免条件从该文件可以看出策略的核心字段metadata.id检查 ID如CKV_AWS_2、metadata.name、metadata.category如ENCRYPTION、metadata.framework以及definition中定义失败define failing的匹配模式与条件。approach: define failing表示该策略以匹配即不合规的方式定义。从加载机制看checkov/common/checks_infra/registry.py 中的_load_checks_from_dir会递归扫描检查目录仅接受.json、.yaml、.yml结尾的文件解析出metadata.id后去重注册同一文件的scope.provider字段会被用于映射支持该策略的 IaC 框架见_get_resource_types方法。2. Composite Policy复合策略跨资源的连接关系判定Composite Policy复合策略或称连接状态策略用于描述资源之间是否或是否不相互连接的关系。典型场景包括某些资源类型必须连接到安全组Security Group某些资源类型不得与其他公开访问的资源相连。每次扫描时Checkov 会基于 Composite Policy 构建一个虚拟连接图virtual connection graph即把 IaC 定义中的资源抽象成图节点、把资源间的引用关系抽象成边再在图上执行连接性判定。关于如何在 YAML 格式中创建 Composite Policy可进一步阅读 YAML Custom Policies 指南。源码佐证连接判定的核心实现在 checkov/common/checks_infra/solvers/connections_solvers/base_connection_solver.py。BaseConnectionSolver类通过resource_types被检查资源类型与connected_resources_types关联资源类型两个集合描述谁与谁相连is_associated_edge(origin_type, destination_type)判断图中一条边的两端是否命中策略关注的资源类型组合base_connection_solver.py#L44-L47reduce_graph_by_target_types会从全量图中抽取只包含目标资源节点与连接块如 Terraform 的output块见SUPPORTED_CONNECTION_BLOCK_TYPES (BlockType.OUTPUT,)的子图再交给具体求解器执行。在 checkov/common/checks_infra/solvers/connections_solvers/ 目录下还包含connection_exists_solver.py、connection_not_exists_solver.py、and_connection_solver.py、or_connection_solver.py、complex_connection_solver.py等求解器分别对应必须存在连接必须不存在连接多条件与/或组合等判定逻辑。可见 Composite Policy 并不是简单属性比对而是一套完整的图求解体系。另外图检查框架graph checks支持的 IaC 框架由 checkov/common/checks_infra/registry.py 中的GraphSupportedIACFrameworks定义包括 Terraform、CloudFormation、Kubernetes、Terraform Plan、Kustomize、Bicep、GitHub Action、Helm、Ansible、ARM 等。3. Incident事件/告警每次不合规的扫描结果Incident事件是每次扫描中针对某一 Policy 的不合规情况所生成的结果条目。一次不合规即产生一个 Incident它承载了检查 ID、检查名称、结果状态、文件路径、行号范围、涉及资源、严重级别等信息。在源码层面每个 Incident 对应checkov/common/output/record.py中的Record类record.py#L36-L98。其关键字段包括check_id/bc_check_id本地检查 ID 与 Bridgecrew 平台检查 IDcheck_result结果对象核心值为CheckResult.PASSED / FAILED / SKIPPED见 checkov/common/models/enums.pyfile_path、file_line_range问题文件与行号范围resource涉及的资源标识severity严重级别LOW、MEDIUM、HIGH、CRITICALcode_block命中代码片段供终端输出展示。在Record.to_string()record.py#L196-L232中PASSED显示为绿色、FAILED显示为红色、SKIPPED显示为蓝色且SKIPPED状态会额外输出Suppress comment说明对应 Suppression 操作。get_unique_string()record.py#L240-L241以检查ID.文件绝对路径.行号范围.资源组成唯一标识用于去重与基线比对。4. Resource资源云平台实体Resource资源指云平台上的实体例如一个 Amazon EC2 实例、一个 CloudFormation 栈、或一个 Amazon S3 存储桶。在 Checkov 的图模型中每个资源是连接图上的一个节点在扫描输出中resource字段用于标识不合规的具体实体。从图构建的角度看checkov/common/graph/graph_builder/ 负责把 IaC 文件解析为节点与边节点属性包含资源类型CustomAttributes.RESOURCE_TYPE与块类型CustomAttributes.BLOCK_TYPE等元数据参见 base_connection_solver.py#L86-L97 中对这些属性的读取。资源地址resource_address则用于在模块调用链中唯一定位资源实例。5. Suppression抑制/豁免将 Incident 标记为可接受Suppression抑制是一种将 Checkov 报告的 Incident 标记为不构成问题的操作。抑制时可以选择对所有相关资源统一抑制仅对特定资源进行抑制。在运行层面Checkov 提供两类互补的手段1代码内注释抑制inline suppression在 IaC 文件中直接写入checkov:skip注释格式一般为#checkov:skipCKV_AWS_123:该资源经安全评审确认为可接受的配置 resource aws_xxx example { # ... }被抑制的检查在结果中以SKIPPED状态呈现并携带抑制原因注释对应Record.to_string()中的Suppress comment输出。2命令行豁免CLI 跳过通过--check与--skip-check参数控制执行范围。根据 CLI Command Reference 与 checkov/common/util/ext_argument_parser.py 中的参数说明# 只运行指定检查其余跳过 checkov -d . --check CKV_AWS_123,CKV_AWS_456 # 跳过指定检查 checkov -d . --skip-check CKV_AWS_123 # 按严重级别跳过跳过所有不高于 MEDIUM 的检查 checkov -d . --skip-check MEDIUM其中--check与--skip-check可组合使用先应用--check列表、再应用--skip-check列表条目既可以是 Checkov 检查 IDCKV_AWS_123、Bridgecrew 检查 IDBC_AWS_GENERAL_123也可以是严重级别LOW、MEDIUM、HIGH、CRITICAL。例如--check CKV_789 --skip-check MEDIUM表示若CKV_789为 HIGH 则运行为 MEDIUM 则跳过。此外Migration.md 还提及--skip-suppressions选项可用于忽略来自平台的抑制规则。Suppression 的深度实现位于 checkov/common/bridgecrew/integration_features/features/suppressions_integration.py负责与 Bridgecrew 平台的抑制策略联动。三、常用术语Commonly used termsInfrastructure as code基础设施即代码基础设施即代码IaC是一类通过机器可读的配置文件来自动化完成基础设施部署、扩缩容与管理的系统。它把传统手工运维转变为配置即版本管理Checkov 的扫描对象正是这些 IaC 文件。Declarative声明式配置声明式Declarative配置是一种以绝对方式描述最终要构建什么的配置方法你声明期望的最终状态执行引擎负责推导并完成所需步骤。声明式风格强调结果定义而非过程细节。Imperative命令式配置命令式Imperative配置是一种以过程化方式描述如何一步步构建出目标结果的配置方法需要显式写出每个执行步骤及其顺序。与声明式相反命令式关注怎么做而非是什么。Immutable infrastructure不可变基础设施不可变基础设施Immutable infrastructure定义了一种受版本控制的数据模型能够复现配置清单中单个属性在特定时间点的变更。它强调基础设施状态的版本化、可回溯与可复现是 IaC 治理与审计的重要基础。TerraformTerraform是一个广受欢迎的开源声明式基础设施即代码框架主要用于在公有云服务中定义资源。在 Checkov 中Terraform 是支持最广泛的扫描框架之一其图检查支持见 checkov/common/checks_infra/registry.py相关策略存放于 checkov/terraform/checks/。CloudFormationCloudFormation是用于在 Amazon Web ServicesAWS中定义资源的声明式基础设施即代码框架。对应检查与图构建实现位于 checkov/cloudformation/包括graph_builder、parser与runner等模块。KubernetesKubernetes是一个广受欢迎的开源声明式基础设施即代码框架主要用于在虚拟计算环境中编排容器。Checkov 对 Kubernetes 的支持体现在 checkov/kubernetes/ 中包含graph_builder、parser、image_referencer与runner等模块并能对 Kubernetes YAML 清单进行配置校验。四、从术语到实战理解一次完整扫描将上述概念串起来Checkov 的一次扫描流程可以这样理解输入 IaC 文件扫描目录/文件如checkov -d .解析为图与资源各框架 runner 将配置解析为 Resource 节点Terraform 的aws_*资源、CloudFormation 的AWS::*资源、Kubernetes 的kind对象等加载 Policy从内置检查目录加载 Python 检查与 YAML 图检查registry.py#L40-L45执行判定普通 Policy 直接比对资源属性Composite Policy 在虚拟连接图上执行连接求解base_connection_solver.py生成 Incident每次不合规生成一条RecordIncident记录检查 ID、文件位置、资源、严重级别等record.py#L36-L98输出与豁免结果按 PASSED/FAILED/SKIPPED 状态输出通过 inline suppression 或--skip-check等参数对 Incident 进行抑制管理。五、结语Policy 定义应该是什么Composite Policy 定义资源之间应该/不应该如何连接Incident 记录哪里不合规Resource 指明针对哪个实体Suppression 提供如何管理误报与豁免。这五个概念构成了阅读 Checkov 扫描报告、编写自定义 YAML 策略、接入 CI/CD 流水线的基础语言。配合 YAML Custom Policies、Python Custom Policies 与 CLI Command Reference 等文档你可以在此基础上进一步构建自己的合规策略体系。【免费下载链接】checkovPrevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.项目地址: https://gitcode.com/GitHub_Trending/ch/checkov创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考