Hermes Agent 容器镜像安全实战4 个阶段锁死基础镜像风险【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent上周有用户反馈 Hermes Agent 容器里的行为跟上周对不上翻构建日志根因就一行基础镜像的latest标签被上游悄悄更新了。那次复盘逼我们把 Hermes Agent 的容器镜像安全整条链路捋了一遍基础镜像选型、镜像版本锁定、CI 更新流水线到运行时加固文中每个动作都能直接在仓库里对着抄。 锁定基础镜像别让 latest 替你选版本latest标签为什么是定时炸弹标签是指针不是快照。你写FROM debian:latest版本选择权就交给了上游下一次构建可能比今天多一个补丁、少一个 CVE。麻烦在于构建照样绿问题要到生产才炸。所以基础镜像选型第一步是钉死具体版本Hermes Agent 的 Dockerfile 里运行时镜像用的就是debian:13.4版本写死想升级只有你手动改才会变。换个说法latest等于把环境一致性这条命交给了注册表的策略。怎么把锁版本再锁一层版本号还有一个口子上游可能对同一个版本号重新打 tag内容悄悄变了。真正的镜像版本锁定锁的是 digest。Hermes Agent 的 uv 来源阶段是这么写的FROM ghcr.io/astral-sh/uv:0.11.6-python3.13-trixiesha256:b3c543…digest 锁的是这一串字节不是叫 0.11.6 的版本。说白了digest 是内容寻址同一个 digest 永远指向同一组层版本号是人起的名人起的名会改。Node 来源阶段同样处理将来升级只需换一行 digest流水线其余部分不用动。版本管该是哪个digest 管到底是什么两层都上才算锁死。多阶段构建把构建工具挡在运行时门外锁版本是一方面缩小攻击面是另一方面。Hermes Agent 把构建拆成多个阶段sqlite_build阶段从源码编译指定版本的 SQLite发行源里的包带着 WAL reset 的旧 bugnode_source阶段取 Node 二进制运行时镜像只COPY --from拿最终产物。build-essential这类编译器和下载工具留在构建阶段永远进不了最终镜像。一句话不运行的东西就是攻击者用不了的东西。锁得再死镜像也会老化——下一步把更新这件事交给流水线。 把更新写进流水线三层分离的 CI 实践怎么让 CI 自动追安全补丁Hermes Agent 的 CI 更新流水线在 docker.yml发布拆成三层各干各的事层职责关键设计detect判断 PR 是否影响镜像tests-only 的 PR 跳过完整构建省 45 分钟build双架构构建 集成测试直接跑刚构建的:test镜像做 docker 测试publish推送并打 tag唯一持有注册表凭据的 job测试全过才运行这样更新基础镜像就变成改 Dockerfile 里的版本或 digest提 PRCI 自动验证兼容性没有手动推了再说的环节。publish 与 build 拆开还有个安全原因PR 构建 job 跑的是外部提交的代码绝不能给它注册表凭据。拉第三方二进制怎么防上游换货构建过程还会从 release 下载 s6-overlay 这类组件Hermes Agent 的规则是下载不做校验就不许解包。Dockerfile 里这段逻辑核心就两行printf %s %s\n ${S6_SHA256} /tmp/s6.tar.xz /tmp/s6.sha256 sha256sum -c /tmp/s6.sha256任何一个 hash 不对整条构建直接失败。sha256 值直接以 ARG 写在 Dockerfile 里审计时对着上游 changelog 核一遍就行。这等于把信任上游网站换成了信任仓库里这串字符。此外还有 osv-scanner.yml 和 supply-chain-audit.yml 定期扫依赖漏洞。流水线保证了进来的干净运行时加固则是容器镜像安全的最后一道门。️ 运行时加固五步缩小攻击面进程为什么必须以非 root 跑容器里进程默认以 root 跑进程一被攻破就是容器内最高权限。Hermes Agent 的做法是构建期建专用用户拷贝时就把权限烙进去RUN useradd -u 10000 -m -d /opt/data hermes COPY --link --chmodarX,go-w . .第一行建 UID 10000 的用户用高位段是为了不跟宿主机的 uid 撞车第二行让非 root 用户对代码目录只有读和执行没有写。docker exec入口也堵上了一个降权 shim 检测到 root 调用时会自动以hermes用户重新执行避免你在/opt/data下写出 root 属主的孤儿文件。只读文件系统之外还能砍掉哪些东西动作做法少掉的风险代码目录只读/opt/hermes非 root 只读可写状态集中到/opt/dataAgent 运行时改不了自己的 venv 把自己搞坏缓存清零装完依赖后清 APT 列表和 npm 缓存攻击面与镜像体积一起下降构建信息入镜HERMES_GIT_SHA构建参数写入.hermes_build_sha线上排障能精确到具体 commit只装生产依赖uv sync --frozen指定 extras不用--all-extras开发/测试依赖不会顺带进生产镜像--frozen这一步别省它强制按仓库里提交的uv.lock解析手改某个依赖版本不会在容器里静默生效。同理npm 侧先拷贝清单再安装锁文件一变才重新装既省构建时间也保证依赖可复现。前面三个阶段走完发布下一版镜像前拿这张清单过一遍。 落地自检清单所有FROM都有明确版本号或sha256digest不存在latest最终镜像里没有构建工具残留的编译器和下载器docker history检查第三方下载全部经过 sha256 校验才解包主进程以非 root 用户运行且 exec 入口有降权兜底只读与可写目录分离代码只读可写状态集中在一个 volumeCI 在推送前先构建并跑集成测试凭据只留在受保护的 job构建参数烙入源码 commit任意容器可回溯版本依赖锁文件在仓库里构建使用--frozen【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hermes Agent 容器镜像安全实战：4 个阶段锁死基础镜像风险
Hermes Agent 容器镜像安全实战4 个阶段锁死基础镜像风险【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent上周有用户反馈 Hermes Agent 容器里的行为跟上周对不上翻构建日志根因就一行基础镜像的latest标签被上游悄悄更新了。那次复盘逼我们把 Hermes Agent 的容器镜像安全整条链路捋了一遍基础镜像选型、镜像版本锁定、CI 更新流水线到运行时加固文中每个动作都能直接在仓库里对着抄。 锁定基础镜像别让 latest 替你选版本latest标签为什么是定时炸弹标签是指针不是快照。你写FROM debian:latest版本选择权就交给了上游下一次构建可能比今天多一个补丁、少一个 CVE。麻烦在于构建照样绿问题要到生产才炸。所以基础镜像选型第一步是钉死具体版本Hermes Agent 的 Dockerfile 里运行时镜像用的就是debian:13.4版本写死想升级只有你手动改才会变。换个说法latest等于把环境一致性这条命交给了注册表的策略。怎么把锁版本再锁一层版本号还有一个口子上游可能对同一个版本号重新打 tag内容悄悄变了。真正的镜像版本锁定锁的是 digest。Hermes Agent 的 uv 来源阶段是这么写的FROM ghcr.io/astral-sh/uv:0.11.6-python3.13-trixiesha256:b3c543…digest 锁的是这一串字节不是叫 0.11.6 的版本。说白了digest 是内容寻址同一个 digest 永远指向同一组层版本号是人起的名人起的名会改。Node 来源阶段同样处理将来升级只需换一行 digest流水线其余部分不用动。版本管该是哪个digest 管到底是什么两层都上才算锁死。多阶段构建把构建工具挡在运行时门外锁版本是一方面缩小攻击面是另一方面。Hermes Agent 把构建拆成多个阶段sqlite_build阶段从源码编译指定版本的 SQLite发行源里的包带着 WAL reset 的旧 bugnode_source阶段取 Node 二进制运行时镜像只COPY --from拿最终产物。build-essential这类编译器和下载工具留在构建阶段永远进不了最终镜像。一句话不运行的东西就是攻击者用不了的东西。锁得再死镜像也会老化——下一步把更新这件事交给流水线。 把更新写进流水线三层分离的 CI 实践怎么让 CI 自动追安全补丁Hermes Agent 的 CI 更新流水线在 docker.yml发布拆成三层各干各的事层职责关键设计detect判断 PR 是否影响镜像tests-only 的 PR 跳过完整构建省 45 分钟build双架构构建 集成测试直接跑刚构建的:test镜像做 docker 测试publish推送并打 tag唯一持有注册表凭据的 job测试全过才运行这样更新基础镜像就变成改 Dockerfile 里的版本或 digest提 PRCI 自动验证兼容性没有手动推了再说的环节。publish 与 build 拆开还有个安全原因PR 构建 job 跑的是外部提交的代码绝不能给它注册表凭据。拉第三方二进制怎么防上游换货构建过程还会从 release 下载 s6-overlay 这类组件Hermes Agent 的规则是下载不做校验就不许解包。Dockerfile 里这段逻辑核心就两行printf %s %s\n ${S6_SHA256} /tmp/s6.tar.xz /tmp/s6.sha256 sha256sum -c /tmp/s6.sha256任何一个 hash 不对整条构建直接失败。sha256 值直接以 ARG 写在 Dockerfile 里审计时对着上游 changelog 核一遍就行。这等于把信任上游网站换成了信任仓库里这串字符。此外还有 osv-scanner.yml 和 supply-chain-audit.yml 定期扫依赖漏洞。流水线保证了进来的干净运行时加固则是容器镜像安全的最后一道门。️ 运行时加固五步缩小攻击面进程为什么必须以非 root 跑容器里进程默认以 root 跑进程一被攻破就是容器内最高权限。Hermes Agent 的做法是构建期建专用用户拷贝时就把权限烙进去RUN useradd -u 10000 -m -d /opt/data hermes COPY --link --chmodarX,go-w . .第一行建 UID 10000 的用户用高位段是为了不跟宿主机的 uid 撞车第二行让非 root 用户对代码目录只有读和执行没有写。docker exec入口也堵上了一个降权 shim 检测到 root 调用时会自动以hermes用户重新执行避免你在/opt/data下写出 root 属主的孤儿文件。只读文件系统之外还能砍掉哪些东西动作做法少掉的风险代码目录只读/opt/hermes非 root 只读可写状态集中到/opt/dataAgent 运行时改不了自己的 venv 把自己搞坏缓存清零装完依赖后清 APT 列表和 npm 缓存攻击面与镜像体积一起下降构建信息入镜HERMES_GIT_SHA构建参数写入.hermes_build_sha线上排障能精确到具体 commit只装生产依赖uv sync --frozen指定 extras不用--all-extras开发/测试依赖不会顺带进生产镜像--frozen这一步别省它强制按仓库里提交的uv.lock解析手改某个依赖版本不会在容器里静默生效。同理npm 侧先拷贝清单再安装锁文件一变才重新装既省构建时间也保证依赖可复现。前面三个阶段走完发布下一版镜像前拿这张清单过一遍。 落地自检清单所有FROM都有明确版本号或sha256digest不存在latest最终镜像里没有构建工具残留的编译器和下载器docker history检查第三方下载全部经过 sha256 校验才解包主进程以非 root 用户运行且 exec 入口有降权兜底只读与可写目录分离代码只读可写状态集中在一个 volumeCI 在推送前先构建并跑集成测试凭据只留在受保护的 job构建参数烙入源码 commit任意容器可回溯版本依赖锁文件在仓库里构建使用--frozen【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考