背景 高性能或底层场景里，Rust 项目经常需要少量 unsafe。问题不在于有没有 unsafe，而在于是否可审计。 审计清单 每个 unsafe block 有明确不变量说明 边界输入做前置校验 单测覆盖成功与失败路径 关键模块做 fuzz 或 Miri 检查 // SAFETY: ptr 来自有效切片起始地址，len 已做边界校验。 unsafe { std::ptr::copy_nonoverlapping(src.as_ptr(), dst.as_mut_ptr(), len); } 总结 unsafe 管理的核心是制度化约束，不是个人经验。 能解释安全前提的 unsafe，才是工程可接受的 unsafe。
背景 镜像漏洞扫描只是起点。上线前还需要回答：这个镜像是谁构建的，包含了什么依赖，是否被篡改。 落地步骤 构建后生成 SBOM 对镜像做签名 部署侧验证签名 syft packages ghcr.io/org/app:latest -o spdx-json > sbom.json cosign sign ghcr.io/org/app:latest cosign verify ghcr.io/org/app:latest 总结 供应链安全要形成闭环：生成、签名、验证，缺一不可。 可观测运行时，也要可追溯构建时。
背景 上一篇聊了 Docker 多阶段构建，重点是镜像体积和构建效率。 但把镜像做小，只解决了一半问题。真正要上线时，还得继续问几个更现实的问题： 镜像里有没有不该带进去的工具 容器是不是还在用 root 运行 依赖包有没有已知漏洞 基础镜像是不是长期没人维护 很多项目的 Dockerfile 确实“能跑”，但离“适合上线”还差不少。 小镜像通常也更安全 这不是绝对规律，但大体成立。 原因很简单： 装得越多，攻击面越大 多余工具越多，漏洞概率越高 调试方便的环境，往往也更容易被滥用 所以镜像瘦身和安全加固，在很多时候是同一个方向上的事情。 不要默认用 root 运行 很多 Dockerfile 最容易忽略的一点，就是进程默认是 root。 FROM alpine:3.20 WORKDIR /app COPY myapp /app/myapp ENTRYPOINT ["/app/myapp"] 这份文件能跑，但容器里的进程权限过大。 更稳妥的方式是显式创建低权限用户： FROM alpine:3.20 RUN addgroup -S appgroup && adduser -S appuser -G appgroup WORKDIR /app COPY myapp /app/myapp USER appuser ENTRYPOINT ["/app/myapp"] 这样即使应用被利用，攻击者拿到的默认权限也会更低。 基础镜像要尽量克制 基础镜像选型很影响最终的安全边界。 常见选择大概是： ubuntu / debian：通用，但内容更多 alpine：体积小，适合简单运行时 distroless：更克制，适合生产环境 scratch：最小，但调试和兼容性要求更高 如果你的程序是静态编译的 Go 服务，通常可以考虑 scratch 或 distroless。 ...