安全扫描

概述 凌晨两点，手机震了一下。磁盘告警——95%。 爬起来一看，Harbor 服务器 /data/registry 目录占了 200GB，里面堆了 3000 多个 tag。有去年测试时推的 app:v0.0.3-beta，有构建失败残留的 app:feature-branch-xxx，还有十个版本的 base image 副本——每个都 800MB 起步。 这不是个例。我在多个团队见过同样的剧本：CI/CD 跑起来之后，镜像只管推不管清，三个月后磁盘就炸。更麻烦的是，有些镜像带着已知 CVE 漏洞跑在生产上，权限管理形同虚设——谁都能推、谁都能拉，项目之间没有隔离。 这篇文章解决三个问题：镜像怎么管权限、怎么拦漏洞、怎么清垃圾。我会用 Harbor（CNCF 毕业项目，目前 GitHub 29k+ star）从安装到生产配置走一遍，每一步都给出可直接复制的配置。如果你刚开始搭制品仓库，或者已经有了但管得稀里糊涂，这篇能帮你少走弯路。 为什么需要制品仓库 先说清楚一个概念：制品仓库（Artifact Repository）不是 Docker Hub。 Docker Hub 是公共镜像托管平台，类似 npm 的 registry。你在上面拉官方镜像没问题，但拿它存公司业务镜像？有几个硬伤： 没有细粒度权限。Docker Hub 的 organization 只有 admin 和普通成员，做不到"测试团队能推 dev 项目、不能碰 prod 项目" 没有漏洞扫描。推上去就推上去了，CVE 该有还是有 没有保留策略。镜像只增不减，除非手动删 网络不稳定。国内拉 Docker Hub 限速、超时是家常便饭 Harbor 解决的就是这些问题。说白了，Harbor = Docker Registry + 权限管理 + 漏洞扫描 + 复制同步 + 审计日志。它像一个带安保、带分拣、带回收站的仓库，而不是一个露天堆场。 类比一下：Docker Hub 像公共停车场，谁都能进；Harbor 像企业内部车库，分区域（项目）、刷卡进（RBAC）、进门安检（漏洞扫描）、定期清退僵尸车（GC + 保留策略）。...

概述 把一个 SAST 工具装进 Jenkins pipeline，扫描跑完显示 0 告警，然后你跟老板说"我们上了 DevSecOps"——这件事我见过太多次了。 在某出行项目的等保 2.0 审计期间，甲方安全团队要求我们在 CI/CD 流水线中集成安全扫描。第一版方案很"标准"：SonarQube 扫代码 + Trivy 扫镜像，门禁设成"Critical 阻断"。上线第一周，流水线红了 47 次。开发团队跑了 47 次"修复"，其中 41 次是误报。第二周开始，有人偷偷在 CI 配置里加了 || true 把扫描结果吞掉。 这就是典型的"装了工具但没解决问题"。安全扫描不是把工具塞进 pipeline 就完事的——它是一个系统工程，涉及工具选型、规则调优、误报治理、门禁策略、开发协作五个层面。这篇文章记录了我们从 70% 误报率降到 5% 的完整改造过程，包括四层安全防御体系的设计、6 个生产级踩坑细节，以及一套可以直接拿去用的 GitLab CI 配置。 如果你正在做安全合规或者想提升团队的安全左移能力，这篇内容能帮你少走几个月弯路。 安全扫描的四层防御体系 很多团队的安全扫描只做一层——要么只跑 SAST，要么只跑 SCA。这就像出门只锁了大门，窗户全开着。真正能拦住漏洞的，是多层防御。我把这套体系分成四层，每层解决不同维度的问题。 第一层：SAST（静态应用安全测试） SAST 扫的是源代码本身。它在代码不运行的情况下，通过词法分析、语法分析和数据流追踪，找出 SQL 注入、XSS、硬编码密码等代码级缺陷。 大白话解释：SAST 就像一个英语老师拿着红笔逐行改你的作文，看到语法错误就圈出来。它不看内容合不合理，只看写法对不对。 主流 SAST 工具对比： 工具 语言覆盖 误报控制 规则定制 CI 集成方式 适用场景 SonarQube 40+ 语言 中等（靠规则集裁剪） Java 插件，重 Scanner + Server 全语言团队，需要质量+安全一体化 Semgrep 30+ 语言 高（AST 模式匹配） YAML 规则，轻量 CLI 直接跑 快速增量扫描，自定义规则多 CodeQL 有限（主要 C/C++/Java/Python/JS） 高（数据流分析） CodeQL 查询语言 GitHub Actions GitHub 生态团队，需要深度漏洞挖掘 我推荐的选择策略：...

概述 你管着一个 K8s 集群，API Server 的 --anonymous-auth=true 没关，etcd 的证书权限是 644，kubelet 的 --read-only-port=10255 还开着——这些东西单独看每个都是"小问题"，但攻击者拿到其中一个入口，就能一路横向打到整个集群。这不是假设，CNCF 2025 年度调查报告显示，超过 90% 的生产 K8s 集群存在至少一个 CIS Benchmark 级别的配置缺陷。 CIS（Center for Internet Security）Benchmark 是一套业界公认的安全配置基线，K8s 有对应的专门版本。kube-bench 就是用来跑这套基线检查的工具——你把它跑一遍，它告诉你哪些配置不符合安全标准、应该怎么改。 但这只是第一步。光跑出报告不够，你还得知道怎么修、怎么持续监控、怎么把扫描嵌进 CI/CD 流水线里。本文从实际操作出发，覆盖从安装 kube-bench、跑第一次扫描、解读报告、修复常见问题，到配合 Trivy 做镜像漏洞扫描、kube-hunter 做渗透模拟、把安全扫描自动化到 GitOps 流程中的完整路径。 CIS Kubernetes Benchmark 是什么 CIS Benchmark 说白了就是一份"安全配置检查清单"。CIS 这个组织拉了一批安全专家，把某个系统（操作系统、数据库、云平台、K8s 等）应该怎么做才算安全，整理成一份文档，每一条都有明确的检查方法和修复建议。 K8s 的 CIS Benchmark 把检查项分成四个层面： 层面 检查对象 典型检查项 控制平面 API Server、Scheduler、Controller Manager、etcd 是否禁用匿名访问、是否启用 RBAC、etcd 是否启用 TLS 工作节点 kubelet、kube-proxy 是否禁用只读端口、是否启用客户端证书认证 策略 RBAC、PodSecurityPolicy/PSA 是否使用最小权限、是否限制特权容器 托管服务 EKS/GKE/AKS 等 云平台特有的安全配置 每个检查项标注了严重级别：L1 是基本要求，任何环境都该满足；L2 是更严格的要求，适用于安全敏感度高的环境。...