docker inspect 本身无自动筛查能力，需配合 grep 等过滤敏感关键词（如 PASSWORD、SECRET、KEY、TOKEN、CREDENTIAL、HOST、URL、_FILE），结合 docker history --no-trunc 检查历史层中隐藏的赋值行为，并对疑似机密镜像立即废弃、重新构建。
直接用 docker inspect 查镜像环境变量本身不带筛查能力，但可以配合过滤和人工判断识别潜在机密。关键不是“自动检测”，而是快速定位高风险字段并人工验证。
重点筛查敏感关键词
镜像中预设的环境变量若含以下关键词，极可能泄露凭证，需立即核查：
-
PASSWORD、PASS、SECRET、KEY、TOKEN、CREDENTIAL（如
DB_PASSWORD=xxx、AWS_SECRET_ACCESS_KEY=xxx） -
HOST、ENDPOINT、URL 中包含内网地址、管理后台或数据库连接串（如
REDIS_URL=redis://admin:pass@10.0.1.5:6379） -
_FILE 类变量（如
CERT_FILE=/etc/ssl/cert.pem），虽不直接暴露内容，但暗示镜像可能打包了证书或密钥文件
用命令快速提取并扫描
避免肉眼翻长列表，用管道组合精准筛选：
- 列出所有环境变量并高亮关键词：
docker inspect --format='{{range .Config.Env}}{{.}}{{println}}{{end}}' nginx:latest | grep -iE '(password|secret|key|token|credential)' - 导出为每行一个变量，方便逐条检查：
docker inspect --format='{{range .Config.Env}}{{.}}{{println}}{{end}}' myapp:prod - 若已知变量名，直接提取值（注意索引从 0 开始）：
docker inspect --format='{{index .Config.Env 2}}' myapp:prod（适用于确认某条是否含敏感内容）
结合 docker history 辅助验证
仅看 .Config.Env 不够——有些敏感值是构建时临时写入、未固化到最终配置，但会留在历史层中：
- 运行
docker history --no-trunc myapp:prod - 重点关注含
ENV、RUN export、COPY的层，尤其是命令里出现等号赋值或 base64 编码内容的行 - 示例可疑输出：
/bin/sh -c #(nop) ENV DB_CONN=postgres://user:hardcoded_pass@db:5432/app
安全边界提醒
发现疑似机密后，不要仅删环境变量了事：
- 该镜像已存在泄露风险，应废弃不用，重新构建（禁用硬编码，改用运行时注入）
- 若变量来自基础镜像（如某定制版 python 镜像自带
API_KEY），需溯源上游并更换可信镜像源 - 生产环境切勿依赖
docker inspect做安全审计，应前置在 CI/CD 中加入静态扫描（如 Trivy config 检查）
