应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载本文深入讲解 tfsec 内置检查项aws-cloudfront-enable-logging它为什么要求每个 AWS CloudFront 分发distribution配置访问日志Access Logging检查失败会产生什么影响以及如何在 Terraform 代码中通过logging_config修复。读完本文你将掌握该检查的判定逻辑、完整修复写法、在命令行与 CI 中的落地方式以及如何结合 tfsec 的忽略、排除与最小严重级别机制灵活管理这一检查项。检查项速览属性值检查 IDaws-cloudfront-enable-logging旧版 IDAWS071见 internal/pkg/legacy/map.go服务aws / cloudfront默认严重级别medium目标资源aws_cloudfront_distribution触发条件未配置logging_config块建议修复为分发启用logging_config访问日志配置该检查项与同属 CloudFront 系列的其他检查aws-cloudfront-enable-waf、aws-cloudfront-enforce-https、aws-cloudfront-use-secure-tls-policy一起收录在 docs/checks/aws/cloudfront/index.md并在 rules.md 中被登记为一条 AWS 规则。为什么需要 CloudFront 访问日志CloudFront 访问日志Access Logging会为分发收到的每一次用户请求生成日志文件其中包含请求时间、客户端 IP、请求方法、URI、响应状态、字节数、Referer、User-Agent 等详细信息。官方文档对本检查的解释是你应该配置 CloudFront Access Logging以创建包含 CloudFront 收到的每个用户请求详细信息的日志文件。从安全与运维角度看访问日志是排查攻击行为、分析访问模式、做合规审计和计费核算的基础数据来源。缺少访问日志意味着发生异常访问或安全事件时没有任何请求级证据可用于溯源等于丢失了关于访问和使用的关键信息——这正是本检查项被标注为 medium 严重级别的原因不直接造成数据泄露但显著削弱可观测性与事后分析能力。判定逻辑有没有logging_config该检查的判定非常直接aws_cloudfront_distribution资源中只要存在logging_config块即视为通过。tfsec 通过 root.go 中的 Terraform 扫描器对 HCL 进行静态解析以 defsec 构建的资源状态模型为基础执行内置规则因此即使logging_config的某些属性不完整例如未设置prefix也不会触发本检查——它只关心日志开关本身是否打开。不安全的示例会失败resource aws_cloudfront_distribution bad_example { // other config // no logging_config }只要资源中没有任何logging_config块运行 tfsec 就会得到一条 ID 为aws-cloudfront-enable-logging、严重级别为 medium 的失败结果。安全的示例会通过resource aws_cloudfront_distribution good_example { // other config logging_config { include_cookies false bucket mylogs.s3.amazonaws.com prefix myprefix } }logging_config块内常用参数说明与 Terraform AWS Provider 的aws_cloudfront_distribution资源定义保持一致参考原文档链接指向的#logging_config小节参数说明备注bucket接收访问日志的 S3 存储桶必填通常写成bucket-name.s3.amazonaws.com形式prefix日志对象键的前缀便于按环境/项目归类可选建议设置如myprefixinclude_cookies是否在日志中包含 Cookie 字段可选默认false出于隐私与日志体积考虑建议保持false注意示例中的bucket值mylogs.s3.amazonaws.com是占位写法实际使用时需替换为真实存在且策略允许 CloudFront 写入的 S3 桶。目标桶通常还应配置生命周期策略以定期归档或清理日志对象避免存储成本无限增长。在命令行与 CI 中验证与落地直接运行检查在包含上述 Terraform 文件的目录中执行tfsec .扫描器会解析目录下所有 HCL 文件命中aws-cloudfront-enable-logging时输出 medium 严重级别的失败结果默认退出码为 1存在 CRITICAL/HIGH/MEDIUM 级别失败时若失败结果全部为 LOW 则退出码为 2全部通过为 0退出码逻辑见 root.go。只关注本检查项想单独验证这一条规则可用--filter-results只保留指定检查tfsec --filter-results aws-cloudfront-enable-logging .该参数最终会通过ScannerWithIncludedRules注入扫描器见 flags.go从而只运行或只输出与规则 ID 匹配的检查。也可用--exclude排除它tfsec --exclude aws-cloudfront-enable-logging .按严重级别门禁该检查默认是 medium。若只希望在高于 medium 的问题上阻断流水线可设置最小严重级别tfsec --minimum-severity HIGH .--minimum-severity支持 CRITICAL、HIGH、MEDIUM、LOW 四个取值见 flags.go非法的取值会在 configureOptions 中被拒绝并报错。也可以在配置文件.tfsec/config.json或config.yml中通过minimum_severity全局控制详见 docs/guides/configuration/config.md。生成多种输出格式CI 中常用--format指定输出lovely、json、csv、checkstyle、junit、sarif、text、markdown、html 等多格式用逗号分隔并配合--out写文件tfsec --format sarif --out tfsec.sarif .临时豁免忽略注解如果某条分发确实不需要访问日志例如仅内部使用的测试分发可在资源上以行内注释豁免resource aws_cloudfront_distribution test_example { #tfsec:ignore:aws-cloudfront-enable-logging // other config // intentionally no logging_config }忽略规则支持多种形态可写在块前、行尾可带过期日期:exp:YYYY-MM-DD可按 workspace 限定:ws:名称旧版 IDAWS071也仍然可用完整语法见 docs/guides/configuration/ignores.md。tfsec 对旧版 ID 的兼容正是通过 internal/pkg/legacy/map.go 中的AWS071 → aws-cloudfront-enable-logging映射实现的运行时由ScannerWithAlternativeIDProvider(legacy.FindIDs)注入见 flags.go。从源码看本检查的定位与运行机制规则登记aws-cloudfront-enable-logging出现在 rules.md 的规则清单中作为 aws/cloudfront 分类下的一条可检索规则旧 ID 兼容旧版 IDAWS071与现用 ID 的映射定义在 internal/pkg/legacy/map.go保证使用旧 ID 配置忽略/排除的存量项目无需修改即可继续生效扫描执行tfsec 命令行入口 cmd/tfsec/main.go 调用 root.go 中基于 defsec 的 Terraform 扫描器内置检查以嵌入式策略随ScannerWithEmbeddedPolicies(true)一并加载见 flags.go因此无需额外下载即可对aws_cloudfront_distribution执行检查结果过滤--filter-results、--exclude、--minimum-severity、--include-passed等参数均在 flags.go 的configureOptions中转换为扫描器选项覆盖从只看这一条到整体门禁的各类使用场景。迁移到 Trivy 的说明tfsec 的 Terraform 扫描引擎与内置规则体系已被整合进 Trivy 的 IaC 与错误配置扫描能力中。当前仓库的 README.md 与 tfsec-to-trivy-migration-guide.md 均说明tfsec 仍可使用但后续工程投入转向 Trivy。在 Trivy 中对应规则仍以相同的检查语义CloudFront 分发需启用访问日志继续生效迁移时注意沿用统一的规则 ID 语义即可。小结你要做的事对应动作让检查通过为每个aws_cloudfront_distribution添加logging_config { bucket ... }单独验证tfsec --filter-results aws-cloudfront-enable-logging .临时豁免资源内添加#tfsec:ignore:aws-cloudfront-enable-logging全局排除tfsec --exclude aws-cloudfront-enable-logging .提高门禁tfsec --minimum-severity HIGH .aws-cloudfront-enable-logging是典型的配置完备性检查修复成本极低一个logging_config块收益却是请求级日志带来的可观测性与审计能力。建议在 Terraform 模块模板中默认开启访问日志并把该检查纳入 CI 门禁从根本上避免上线后发现没有日志的被动局面。参考链接原文保留Terraform AWS Provider 文档aws_cloudfront_distribution资源的logging_config参数说明见原文档 docs/checks/aws/cloudfront/enable-logging/index.md 的 Links 小节AWS CloudFront 开发指南Access Logs 使用说明同上 Links 小节赞分享应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载相关推荐tfsec 检查规则详解启用 AWS ECR 镜像扫描aws-ecr-enable-image-scanstfsec 检查规则详解启用 AWS ECR 镜像扫描aws ecr enable image scans 本篇技术指南围绕 tfsec 内置检查规则 a应用安全SASTIaCNanobot OpenAI 兼容 API 完整指南用 /v1/chat/completions 把本地 Agent 接入任何应用Nanobot OpenAI 兼容 API 完整指南用 /v1/chat/completions 把本地 Agent 接入任何应用 Nanobot 内置了一套应用安全SASTIaCtfsec 静态检查实战为 AWS Elasticsearch 域启用静态加密aws-elastic-search-enable-domain-encryptiontfsec 静态检查实战为 AWS Elasticsearch 域启用静态加密aws elastic search enable domain encryp应用安全SASTIaC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 tfsec 检查项详解：为 CloudFront 分发开启 Access Logging（aws-cloudfront-enable-logging）
应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载本文深入讲解 tfsec 内置检查项aws-cloudfront-enable-logging它为什么要求每个 AWS CloudFront 分发distribution配置访问日志Access Logging检查失败会产生什么影响以及如何在 Terraform 代码中通过logging_config修复。读完本文你将掌握该检查的判定逻辑、完整修复写法、在命令行与 CI 中的落地方式以及如何结合 tfsec 的忽略、排除与最小严重级别机制灵活管理这一检查项。检查项速览属性值检查 IDaws-cloudfront-enable-logging旧版 IDAWS071见 internal/pkg/legacy/map.go服务aws / cloudfront默认严重级别medium目标资源aws_cloudfront_distribution触发条件未配置logging_config块建议修复为分发启用logging_config访问日志配置该检查项与同属 CloudFront 系列的其他检查aws-cloudfront-enable-waf、aws-cloudfront-enforce-https、aws-cloudfront-use-secure-tls-policy一起收录在 docs/checks/aws/cloudfront/index.md并在 rules.md 中被登记为一条 AWS 规则。为什么需要 CloudFront 访问日志CloudFront 访问日志Access Logging会为分发收到的每一次用户请求生成日志文件其中包含请求时间、客户端 IP、请求方法、URI、响应状态、字节数、Referer、User-Agent 等详细信息。官方文档对本检查的解释是你应该配置 CloudFront Access Logging以创建包含 CloudFront 收到的每个用户请求详细信息的日志文件。从安全与运维角度看访问日志是排查攻击行为、分析访问模式、做合规审计和计费核算的基础数据来源。缺少访问日志意味着发生异常访问或安全事件时没有任何请求级证据可用于溯源等于丢失了关于访问和使用的关键信息——这正是本检查项被标注为 medium 严重级别的原因不直接造成数据泄露但显著削弱可观测性与事后分析能力。判定逻辑有没有logging_config该检查的判定非常直接aws_cloudfront_distribution资源中只要存在logging_config块即视为通过。tfsec 通过 root.go 中的 Terraform 扫描器对 HCL 进行静态解析以 defsec 构建的资源状态模型为基础执行内置规则因此即使logging_config的某些属性不完整例如未设置prefix也不会触发本检查——它只关心日志开关本身是否打开。不安全的示例会失败resource aws_cloudfront_distribution bad_example { // other config // no logging_config }只要资源中没有任何logging_config块运行 tfsec 就会得到一条 ID 为aws-cloudfront-enable-logging、严重级别为 medium 的失败结果。安全的示例会通过resource aws_cloudfront_distribution good_example { // other config logging_config { include_cookies false bucket mylogs.s3.amazonaws.com prefix myprefix } }logging_config块内常用参数说明与 Terraform AWS Provider 的aws_cloudfront_distribution资源定义保持一致参考原文档链接指向的#logging_config小节参数说明备注bucket接收访问日志的 S3 存储桶必填通常写成bucket-name.s3.amazonaws.com形式prefix日志对象键的前缀便于按环境/项目归类可选建议设置如myprefixinclude_cookies是否在日志中包含 Cookie 字段可选默认false出于隐私与日志体积考虑建议保持false注意示例中的bucket值mylogs.s3.amazonaws.com是占位写法实际使用时需替换为真实存在且策略允许 CloudFront 写入的 S3 桶。目标桶通常还应配置生命周期策略以定期归档或清理日志对象避免存储成本无限增长。在命令行与 CI 中验证与落地直接运行检查在包含上述 Terraform 文件的目录中执行tfsec .扫描器会解析目录下所有 HCL 文件命中aws-cloudfront-enable-logging时输出 medium 严重级别的失败结果默认退出码为 1存在 CRITICAL/HIGH/MEDIUM 级别失败时若失败结果全部为 LOW 则退出码为 2全部通过为 0退出码逻辑见 root.go。只关注本检查项想单独验证这一条规则可用--filter-results只保留指定检查tfsec --filter-results aws-cloudfront-enable-logging .该参数最终会通过ScannerWithIncludedRules注入扫描器见 flags.go从而只运行或只输出与规则 ID 匹配的检查。也可用--exclude排除它tfsec --exclude aws-cloudfront-enable-logging .按严重级别门禁该检查默认是 medium。若只希望在高于 medium 的问题上阻断流水线可设置最小严重级别tfsec --minimum-severity HIGH .--minimum-severity支持 CRITICAL、HIGH、MEDIUM、LOW 四个取值见 flags.go非法的取值会在 configureOptions 中被拒绝并报错。也可以在配置文件.tfsec/config.json或config.yml中通过minimum_severity全局控制详见 docs/guides/configuration/config.md。生成多种输出格式CI 中常用--format指定输出lovely、json、csv、checkstyle、junit、sarif、text、markdown、html 等多格式用逗号分隔并配合--out写文件tfsec --format sarif --out tfsec.sarif .临时豁免忽略注解如果某条分发确实不需要访问日志例如仅内部使用的测试分发可在资源上以行内注释豁免resource aws_cloudfront_distribution test_example { #tfsec:ignore:aws-cloudfront-enable-logging // other config // intentionally no logging_config }忽略规则支持多种形态可写在块前、行尾可带过期日期:exp:YYYY-MM-DD可按 workspace 限定:ws:名称旧版 IDAWS071也仍然可用完整语法见 docs/guides/configuration/ignores.md。tfsec 对旧版 ID 的兼容正是通过 internal/pkg/legacy/map.go 中的AWS071 → aws-cloudfront-enable-logging映射实现的运行时由ScannerWithAlternativeIDProvider(legacy.FindIDs)注入见 flags.go。从源码看本检查的定位与运行机制规则登记aws-cloudfront-enable-logging出现在 rules.md 的规则清单中作为 aws/cloudfront 分类下的一条可检索规则旧 ID 兼容旧版 IDAWS071与现用 ID 的映射定义在 internal/pkg/legacy/map.go保证使用旧 ID 配置忽略/排除的存量项目无需修改即可继续生效扫描执行tfsec 命令行入口 cmd/tfsec/main.go 调用 root.go 中基于 defsec 的 Terraform 扫描器内置检查以嵌入式策略随ScannerWithEmbeddedPolicies(true)一并加载见 flags.go因此无需额外下载即可对aws_cloudfront_distribution执行检查结果过滤--filter-results、--exclude、--minimum-severity、--include-passed等参数均在 flags.go 的configureOptions中转换为扫描器选项覆盖从只看这一条到整体门禁的各类使用场景。迁移到 Trivy 的说明tfsec 的 Terraform 扫描引擎与内置规则体系已被整合进 Trivy 的 IaC 与错误配置扫描能力中。当前仓库的 README.md 与 tfsec-to-trivy-migration-guide.md 均说明tfsec 仍可使用但后续工程投入转向 Trivy。在 Trivy 中对应规则仍以相同的检查语义CloudFront 分发需启用访问日志继续生效迁移时注意沿用统一的规则 ID 语义即可。小结你要做的事对应动作让检查通过为每个aws_cloudfront_distribution添加logging_config { bucket ... }单独验证tfsec --filter-results aws-cloudfront-enable-logging .临时豁免资源内添加#tfsec:ignore:aws-cloudfront-enable-logging全局排除tfsec --exclude aws-cloudfront-enable-logging .提高门禁tfsec --minimum-severity HIGH .aws-cloudfront-enable-logging是典型的配置完备性检查修复成本极低一个logging_config块收益却是请求级日志带来的可观测性与审计能力。建议在 Terraform 模块模板中默认开启访问日志并把该检查纳入 CI 门禁从根本上避免上线后发现没有日志的被动局面。参考链接原文保留Terraform AWS Provider 文档aws_cloudfront_distribution资源的logging_config参数说明见原文档 docs/checks/aws/cloudfront/enable-logging/index.md 的 Links 小节AWS CloudFront 开发指南Access Logs 使用说明同上 Links 小节赞分享应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载相关推荐tfsec 检查规则详解启用 AWS ECR 镜像扫描aws-ecr-enable-image-scanstfsec 检查规则详解启用 AWS ECR 镜像扫描aws ecr enable image scans 本篇技术指南围绕 tfsec 内置检查规则 a应用安全SASTIaCNanobot OpenAI 兼容 API 完整指南用 /v1/chat/completions 把本地 Agent 接入任何应用Nanobot OpenAI 兼容 API 完整指南用 /v1/chat/completions 把本地 Agent 接入任何应用 Nanobot 内置了一套应用安全SASTIaCtfsec 静态检查实战为 AWS Elasticsearch 域启用静态加密aws-elastic-search-enable-domain-encryptiontfsec 静态检查实战为 AWS Elasticsearch 域启用静态加密aws elastic search enable domain encryp应用安全SASTIaC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考