diff --git a/content/zh-cn/docs/concepts/security/security-checklist.md b/content/zh-cn/docs/concepts/security/security-checklist.md
index 03530e0c61..497659e8b8 100644
--- a/content/zh-cn/docs/concepts/security/security-checklist.md
+++ b/content/zh-cn/docs/concepts/security/security-checklist.md
@@ -28,6 +28,7 @@ On how to read and use this document:
 此清单不求详尽无遗，是预计会不断演化的。
 
 关于如何阅读和使用本文档：
+
 - 主题的顺序并不代表优先级的顺序。
 - 在每章节的列表下面的段落中，都详细列举了一些检查清项目。
 
@@ -101,7 +102,7 @@ an admin user.
 
 - [ ] 使用的 CNI 插件可支持网络策略。
 - [ ] 对集群中的所有工作负载应用入站和出站的网络策略。
-- [ ] 落实每个名称空间内的默认网络策略，覆盖所有 Pod，拒绝一切访问。
+- [ ] 落实每个名字空间内的默认网络策略，覆盖所有 Pod，拒绝一切访问。
 - [ ] 如果合适，使用服务网格来加密集群内的所有通信。
 - [ ] 不在互联网上公开 Kubernetes API、kubelet API 和 etcd。
 - [ ] 过滤工作负载对云元数据 API 的访问。
@@ -120,8 +121,8 @@ is missed.
 许多[容器网络接口（Container Network Interface，CNI）插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)提供了限制
 Pod 可能与之通信的网络资源的功能。
 这种限制通常通过[网络策略](/zh-cn/docs/concepts/services-networking/network-policies/)来完成，
-网络策略提供了一种名称空间作用域的资源来定义规则。
-在每个名称空间中，默认的网络策略会阻塞所有的出入站流量，并选择所有 Pod，
+网络策略提供了一种名字空间作用域的资源来定义规则。
+在每个名字空间中，默认的网络策略会阻塞所有的出入站流量，并选择所有 Pod，
 采用允许列表的方法很有用，可以确保不遗漏任何工作负载。
 
 <!--
@@ -226,8 +227,8 @@ admission can be easily combined with admission webhooks and external services.
 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)定义了三种不同的策略：
 特权策略（Privileged）、基线策略（Baseline）和限制策略（Restricted），它们限制了 `PodSpec` 中关于安全的字段的设置。
 这些标准可以通过默认启用的新的
-[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入 Webhook 在名称空间级别强制执行。
-请注意，与它所取代的、已被删除的 PodSecurityPolicy 准入机制相反，
+[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入 Webhook 在名字空间级别强制执行。
+请注意，与它所取代的、已被移除的 PodSecurityPolicy 准入机制相反，
 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)可以轻松地与准入 Webhook 和外部服务相结合使用。
 
 <!--
@@ -307,7 +308,6 @@ profile can be found [in containerd](https://github.com/containerd/containerd/bl
 as well. Fortunately, [Seccomp Default](/blog/2021/08/25/seccomp-default/), a
 new alpha feature to use a default seccomp profile for all workloads can now be
 enabled and tested.
-
 -->
 从历史背景看，请注意 Docker 自 2016 年以来一直使用[默认的 Seccomp 配置文件](https://docs.docker.com/engine/security/seccomp/)，
 仅允许来自 [Docker Engine 1.10](https://www.docker.com/blog/docker-engine-1-10-security/) 的很小的一组系统调用，
@@ -342,7 +342,7 @@ violations. AppArmor profiles are enforced on a per-container basis, with an
 annotation, allowing for processes to gain just the right privileges.
 -->
 [AppArmor](https://apparmor.net/) 是一个 Linux 内核安全模块，
-可以提供一种简单的方法来实现强制访问控制（Mandatory Access Control， MAC）并通过系统日志进行更好地审计。
+可以提供一种简单的方法来实现强制访问控制（Mandatory Access Control, MAC）并通过系统日志进行更好地审计。
 要在 Kubernetes 中[启用 AppArmor](/zh-cn/docs/tutorials/security/apparmor/)，至少需要 1.4 版本。
 与 Seccomp 一样，AppArmor 也通过配置文件进行配置，
 其中每个配置文件要么在强制（Enforcing）模式下运行，即阻止访问不允许的资源，要么在投诉（Complaining）模式下运行，只报告违规行为。
@@ -508,15 +508,16 @@ for time-bound service account credentials.
 - [ ] Container images are configured to be run as unprivileged user.
 - [ ] References to container images are made by sha256 digests (rather than
 tags) or the provenance of the image is validated by verifying the image's
-digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller).
+digital signature at deploy time [via admission control](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller).
 - [ ] Container images are regularly scanned during creation and in deployment, and
   known vulnerable software is patched.
 -->
 ## 镜像 {#images}
+
 - [ ] 尽量减少容器镜像中不必要的内容。
 - [ ] 容器镜像配置为以非特权用户身份运行。
 - [ ] 对容器镜像的引用是通过 Sha256 摘要实现的，而不是标签（tags），
-  或者[通过准入控制器](/zh-cn/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)在部署时验证镜像的数字签名来验证镜像的来源。
+  或者[通过准入控制器](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)在部署时验证镜像的数字签名来验证镜像的来源。
 - [ ] 在创建和部署过程中定期扫描容器镜像，并对已知的漏洞软件进行修补。
 
 <!--
@@ -553,14 +554,14 @@ Avoid using image tags to reference an image, especially the `latest` tag, the
 image behind a tag can be easily modified in a registry. Prefer using the
 complete `sha256` digest which is unique to the image manifest. This policy can be
 enforced via an [ImagePolicyWebhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook).
-Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-images/#verifying-image-signatures-with-admission-controller)
+Image signatures can also be automatically [verified with an admission controller](/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)
 at deploy time to validate their authenticity and integrity.
 -->
 避免使用镜像标签来引用镜像，尤其是 `latest` 标签，因为标签对应的镜像可以在仓库中被轻松地修改。
 首选使用完整的 `Sha256` 摘要，该摘要对特定镜像清单文件而言是唯一的。
 可以通过 [ImagePolicyWebhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
 强制执行此策略。
-镜像签名还可以在部署时由[准入控制器自动验证](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)，
+镜像签名还可以在部署时由[准入控制器自动验证](/zh-cn/docs/tasks/administer-cluster/verify-signed-artifacts/#verifying-image-signatures-with-admission-controller)，
 以验证其真实性和完整性。
 
 <!--
@@ -642,7 +643,7 @@ permission to sign certificate requests.
 attribute') of `system:masters`.
 -->
 [`CertificateSubjectRestriction`](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction)
-: 拒绝将 `group`（或 `organization attribute` ）设置为 `system:masters` 的所有证书请求。
+: 拒绝将 `group`（或 `organization attribute`）设置为 `system:masters` 的所有证书请求。
 
 <!--
 [`LimitRanger`](/docs/reference/access-authn-authz/admission-controllers/#limitranger)
@@ -741,7 +742,7 @@ has permissions to use the image.
 - [Blog post "A Closer Look at NSA/CISA Kubernetes Hardening Guidance"](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images)
   for complementary resource on hardening Kubernetes clusters.
 -->
-## 接下来
+## 接下来  {#what-is-next}
 
 - [RBAC 良好实践](/zh-cn/docs/concepts/security/rbac-good-practices/)提供有关授权的更多信息。
 - [集群多租户指南](/zh-cn/docs/concepts/security/multi-tenancy/)提供有关多租户的配置选项建议和最佳实践。