公司用的某商业报表系统，只有编译好的二进制包，没源码，也没文档。运维小张把它打成 Docker 镜像，直接 run -d --privileged 启动，结果三天后被扫出 443 端口反向 shell ——不是漏洞多，是默认配置+过度权限惹的祸。
镜像构建阶段：别让敏感信息躺平在层里
闭源程序没法 audit 源码，但能管住构建过程。比如用非 root 用户运行：
FROM ubuntu:22.04
COPY ./report-engine /app/
RUN groupadd -g 1001 -r report && useradd -r -u 1001 -g report report
USER report
EXPOSE 8080
ENTRYPOINT ["/app/report-engine"]千万别在 Dockerfile 里写 ENV LICENSE_KEY=xxx 或 COPY .env ./，这类信息会固化进镜像层，哪怕后续 RUN rm -f .env 也删不干净。实际做法是启动时通过 --env-file 或 Kubernetes Secret 注入。
运行时加固：权限不是越宽越好
闭源程序常默认监听 0.0.0.0:8080、读写 /tmp、挂载整个 /var/log。上线前必须做三件事：
- 加 --read-only 启动，只对必要路径加 --tmpfs 或 -v /app/logs:/app/logs:rw；
- 禁用不必要的 capabilities：
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE ...； - 用 --security-opt=no-new-privileges 防止进程提权。
某次部署财务插件，对方要求挂载宿主机 /etc/passwd ——直接拒掉，改用 --userns=host + 显式映射 uid/gid，既满足权限需求又不暴露系统文件。
网络路由层面：闭源服务不是法外之地
“路由设置”栏目不是白叫的。闭源容器跑起来后，它的出入流量必须受控：
比如 Nginx 反代这个报表服务，只允许内网 10.10.20.0/24 访问，且强制走 HTTPS：
location /report/ {
allow 10.10.20.0/24;
deny all;
proxy_pass http://report-container:8080/;
proxy_set_header X-Forwarded-Proto https;
}再配合 iptables 或云平台安全组，把容器端口（如 8080）仅对反代服务器开放，彻底阻断外部直连。很多闭源服务自带管理后台，默认无密码或弱密码，靠一层路由隔离比指望它自己做好认证靠谱得多。
最后提醒一句：别信“厂商说安全就安全”。上周遇到一个闭源日志采集器，启动后自动往境外域名发心跳包——查进程树才发现它偷偷拉了 curl 和 python3。容器里跑闭源程序，得当它是个黑盒子，只给最小必要环境，其余全靠外围卡死。