很多团队把 Go 程序编译出来就直接丢上线了。go build 一敲，二进制文件往服务器一扔，完事。
问题在于，默认编译出来的产物里藏了不少东西。你的源码路径、构建环境信息、调试符号全在里面。对开发者来说无所谓，但这些东西一旦进入生产环境，就成了攻击者的情报来源。
我整理了一套 Go 程序发布的安全基线，涵盖了构建参数、依赖控制和分发验证三个层面。
路径和内存布局
先说一个容易被忽略的细节。Go 编译器默认会把源码的绝对路径写进二进制文件。你在 /home/zhangsan/project 下编译，这个路径就永远刻进了产物里。通过 go version -m 可以直接看到。
-trimpath 就是干这个的，它把路径信息擦干净。这不是什么高深操作，但很多项目连这步都没做。
再往上走一步是 -buildmode=pie。PIE（Position Independent Executable）让程序每次运行时的内存地址都不一样。没有 PIE 的情况下，同一个二进制文件每次加载到相同的内存位置，攻击者可以靠硬编码地址写 exploit。开了 PIE 之后，地址每次都变，攻击成本直接拉高。大多数 Linux 发行版这几年已经把 PIE 作为默认选项了，Go 程序也应该跟上。
砍掉不必要的依赖
Go 的卖点之一就是编译成单个二进制文件，不依赖外部库。但 CGO 一开，这事就打了折扣。
CGO_ENABLED=0 直接禁用 CGO，程序不再依赖系统的 libc。这有两个好处：一是实现了真正的静态编译，二进制文件丢到任何 Linux 机器上都能跑；二是避开了 libc 本身的安全问题。glibc 历史上的漏洞不少，Heartbleed 虽然是 OpenSSL 的，但类似的底层库安全问题一直没断过。
配合 scratch 或 distroless 基础镜像使用效果更好。这些镜像里连 shell 都没有，攻击者就算拿到了容器权限，也找不到可用的工具。攻击面小了，出事的概率就低。
让发布物可验证
校验和（Checksum）大家都在用，但它只能证明文件没损坏，不能证明文件是你发的。供应链攻击这几年越来越频繁，谁能保证你下载的二进制文件没被人动过？
Cosign 可以对容器镜像或二进制文件做数字签名，验证方用公钥就能确认来源。SBOM（Software Bill of Materials）是另一层保障，它把编译时用到的所有依赖版本都列出来。出了漏洞，拿着 SBOM 一查就知道自己有没有中招。
构建证据（Provenance）记录的是"这个二进制文件是在什么环境、由谁、从哪个 commit 编译出来的"。三个东西配合起来：签名确认来源，SBOM 列出内容，Provenance 记录过程。
安全构建命令
把上面的要点整合到一起，得到这样一个构建命令：
| |
参数解释：-trimpath 去掉源码路径，-buildmode=pie 开启地址随机化，-ldflags="-s -w" 去掉调试符号和 DWARF 信息，-extldflags=-static 确保纯静态链接。-buildvcs=false 则避免把 git 信息嵌入二进制文件。
这些参数加起来不会让编译变慢，不会影响运行性能，但能堵上好几个常见的信息泄露和攻击向量。没有理由不用。