北京
zaerohell 在翻看自己 riviera-industrial-erp 仓库的提交记录时，目光停在 docker-compose.yml 上就不动了——CLICKUP_API_KEY 明晃晃地写在服务环境变量里。他心里一紧：这份密钥随时可能顺着某次 git push 流进公开共享的镜像层里。
问题出在硬编码。docker-compose.yml 原本直接把 API 密钥以明文方式嵌在 services 配置中，每一条环境变量都是“写死”的字符串。按官方安全实践，这类敏感信息不该进入版本控制，可当时就躺在那儿，没有一次构建能绕开它。仓库的提交信息也证实了这个修复目标：fix: CLICKUP_API_KEY en docker-compose.yml via ${} desde .env host，直接点明了要将密钥注入方式换成从宿主机 .env 文件中读取。
改动过程本身很轻量。zaerohell 先在 docker-compose.yml 的服务定义里添加了两条环境变量：DISABLE_RATE_LIMIT: "true" 和 CLICKUP_API_KEY: ${CLICKUP_API_KEY}。Diff 显示了变化的精确位置——就在 NEXTAUTH_SECRET、NEXTAUTH_URL 和 STORAGE_DRIVER 之下。完成后，他又在宿主机根目录建了一个 .env 文件，写入 CLICKUP_API_KEY=your_api_key_here。
这里的核心机制是 Docker Compose 的变量替换扩展。当 Compose 看到 ${CLICKUP_API_KEY} 语法，会优先在宿主机的环境变量中查找同名字段；找不到时，就自动回退到同目录下 .env 文件里的定义。好处很直接：密钥脱离代码仓库，变成了可以按环境替换的配置项，开发、测试、生产各用各的密钥，文件换一下就行。
不过 zaerohell 也清楚，这件事才做了一半。.env 文件虽然不再跟代码走，但如果没被 .gitignore 拦下，还是会偶然上传。于是他在仓库根目录的忽略列表里补上了这一行，并计划后续引入密钥管理器，把敏感值挪到更受控的地方。这次的修复算是把消防通道先打通了。
整个经历透露了一个产品构建中的现实节奏：安全债务常常是累积出来的，最初为了跑通流程留下的硬编码，后来都得还。能主动在一次代码审计里发现并修正，而不是被漏洞报告推着走，已经比多数项目快了一步。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
