应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载本文围绕 openai/codex-security 仓库的 docker/README.md 展开完整讲解ghcr.io/openai/codex-security容器镜像的发布机制、镜像验证方法、GHCR 管理员初始化流程以及基于 Compose 的 scanner 运行器workflow runner与 findings 服务在同一镜像上的部署、连接与数据持久化方案。读完本文你将掌握如何解析并校验镜像 digest、通过CODEX_SECURITY_IMAGE与CODEX_SECURITY_FINDINGS_IMAGE选择可信镜像、运行容器化批量扫描与去重工作流以及在不丢失状态的前提下安全升级和迁移 findings 服务。镜像发布机制一份镜像两种角色container-release工作流把默认的scannerDocker 构建目标发布为ghcr.io/openai/codex-security。这个单一镜像同时承载两个角色scanner以镜像默认命令运行扫描器 CLIDockerfile 中ENTRYPOINT为入口脚本CMD为--helpfindings 服务以 Node 服务器命令启动见 compose.findings.yaml共享同一镜像但在独立容器、独立状态中运行。发布版本使用 SDK 包版本号、原生 Linuxamd64/arm64构建产物、BuildKit SBOM 与 maximum-mode provenance并附加 GitHub provenance attestation。每个原生镜像在发布多架构 manifest 之前都必须通过 scanner 与 findings 的 API/持久化检查。匿名拉取和 attestation 验证成功后才会推进version、sha-commit与latest三类 tag。稳定版本 tag 一旦发布即不可覆盖——这正是 verify-container-release-version.sh 脚本的职责它在发布前用gh api分页查询 GHCR 包版本若目标 tag 已存在则直接以非零状态拒绝发布。镜像元数据与验证流程发布镜像在每个平台的镜像 labels 以及最终多架构 index 中都带有 OCI 元数据title、description、source、license、vendor、version、source commit、build timestamp、release notes以及固定到该 commit 的 documentation。GHCR 从 index 读取多架构描述而不是仅依赖 Dockerfile labels。工作流为两种架构只生成一次元数据在已发布的候选镜像上验证然后对该确切 digest签名并提升 tag。元数据变更意味着新 digest、新 release已有稳定版本不会被更新。成功发布后workflow summary 会包含 digest、支持的平台、文档链接以及拉取和验证镜像的命令。用下面的命令完成解析 index digest → 校验 → 拉取完整流程把VERSION替换为可用的稳定版本imageghcr.io/openai/codex-security versionVERSION digest$(docker buildx imagetools inspect $image:$version --format {{.Manifest.Digest}}) reference$image$digest docker buildx imagetools inspect $reference --raw | jq .annotations gh attestation verify oci://$reference --repo openai/codex-security docker pull $referencereference形如ghcr.io/openai/codex-securitysha256:...是部署时使用的可信标识。index 会按运行架构自动选择原生amd64或arm64镜像其中unknown/unknown条目对应各平台的 SBOM 与构建 provenance它们不是可运行平台不应被移除。有一点需要特别强调所有 labels、annotations、SBOM 与 provenance 都是公开的切勿在其中放入私有 URL、扫描数据或凭据。BuildKit 的 maximum-mode provenance 会包含 build arguments因此构建凭据应通过 secret mounts 传入而不是 build arguments。从源码构建镜像若要测试未发布的 checkout可先准备通用原生 payload即native/prebuilt下的 8 个平台二进制与共享 notices再本地构建scanner目标docker build --target scanner -t codex-security:local . export CODEX_SECURITY_IMAGEcodex-security:localscanner构建阶段基于node:22-bookworm-slim全局安装 npm 包后依次执行codex-security --version与codex-security bulk-scan --help做冒烟验证随后创建 UID/GID 均为10001的非 root 用户codex-security并预建/input、/output、/state目录见 Dockerfile。GHCR 管理员初始化首次发布前管理员需要完成三件事允许组织级创建包若包不存在则引导创建使用一个经过评审的镜像加非 release tagdocker build --target scanner -t ghcr.io/openai/codex-security:bootstrap . printf %s $CR_PAT | docker login ghcr.io --username YOUR_GITHUB_USER --password-stdin docker push ghcr.io/openai/codex-security:bootstrap docker logout ghcr.io使用具备write:packages权限的 personal access tokenclassic必要时为 SSO 授权绝不将其提交到仓库或传入构建。在包设置中关联openai/codex-security仓库可见性设为Public并在Manage Actions access下授予仓库Write权限。工作流使用GITHUB_TOKEN对于缺失、私有或不可读的包会直接拒绝。登出 GHCR 后应验证docker pull可用。保护container环境为受保护的main分支与已批准的container-v*tag 配置 required reviewers 和 deployment rules允许工作流使用固定的pinnedactions、包写入与 OIDC attestations。若 branch-protection 的 check names 仍引用旧的 release jobs需要一并更新。发布流程合并到main后推送与 SDK 包版本一致的container-vversiontag或在main上手动运行container-release。Release 要求受保护main上有提交pull request 只会构建和测试。若发布失败修复原因后只重跑失败的 job不要覆盖已存在的稳定版本。bootstrap与release-candidate-committag 均非消费者可用版本。Workflow runner以 scanner 镜像运行 CLIcompose.runner.yaml从scanner镜像运行打包好的 CLI它不会启动 findings 服务也不是另一个工作流引擎——命令、输出和退出码都直接透传既有 scanner entrypointcompose.runner.yaml 中默认command: [--help]。在仓库根目录执行以下命令。先准备私有目录并选择宿主用户的 UID/GID以便 runner 写入 bind mountsmkdir -p results state chmod 700 results state export CODEX_SECURITY_USER$(id -u):$(id -g) export CODEX_SECURITY_IMAGEghcr.io/openai/codex-security:latest docker compose -f compose.runner.yaml pull docker compose -f compose.runner.yaml run --rm codex-security login --device-auth无人值守场景可改用OPENAI_API_KEY或CODEX_API_KEY代替登录。Git 认证复用既有的GH_TOKEN/GITHUB_TOKEN与可选的CODEX_SECURITY_GIT_HOST设置——entrypoint 脚本会据此注入git config把githost:重写为 HTTPS 并挂接 git-credential.sh 凭据助手。只传入 runner 需要的凭据findings 服务的 embedding 凭据单独配置。可重复部署建议在CODEX_SECURITY_IMAGE中使用具体版本或 digest。持久化目录设计runner 依赖两个宿主目录由CODEX_SECURITY_RESULTS与CODEX_SECURITY_STATE指定默认./results与./state映射关系如下容器路径持久化内容/output扫描产物及存放在此的源码 checkout/output/.codex-security-stateCLI 扫描历史与 workbench 数据库/stateCodex 登录态与配置三个位置在替换 runner 时都要保留。已批准的源码 checkout 也应保持在同一容器路径便于后续源码复审。例如把 checkout 放在results/repository下然后扫描它并把产物输出到 checkout 之外docker compose -f compose.runner.yaml run --rm codex-security \ scan /output/repository --output-dir /output/scans/run-001 --headless已有 checkout 也可以用run --volume /absolute/repository:/input/repository额外 bind-mount每个需要源码的阶段都要重复挂载。注意把宿主扫描的文件搬进这些目录不会改写其已保存状态中的绝对路径——要么在 runner 内完成扫描要么保留原始路径。绝不要把 runner 的 workbench 数据库或 Codex home 与 findings 服务的/state卷混用。连接 findings 服务独立托管的服务可通过既有--findings-url传入其可达的 base URL。注意容器内 loopback 地址指向 runner 自身而不是 Docker 宿主或其它容器。findings API 没有内置认证应使用私有网络或认证 TLS 代理不得把未认证的 API 暴露到公网。同引擎部署时把服务作为独立 Compose 项目启动docker compose -p findings -f compose.findings.yaml up -d保存仅含网络配置的 override 为compose.runner.local.yamlnetworks: default: external: true name: findings_default然后以不同项目名在该既有网络上运行 runner。服务即使宿主端口仅绑定 loopback也可通过 Compose DNS 名称访问docker compose -p runner -f compose.runner.yaml -f compose.runner.local.yaml \ run --rm codex-security dedupe --scan SCAN_ID \ --findings-url http://findings:3000 --jsonSCAN_ID取自已完成扫描首次导入 findings 时需携带匹配的 repository ID用scan-manifest.json中的scan.target.targetId详见 findings 服务指南。远端服务则省略 network override、直接给 URL。停止或替换 runner 不会停止服务也不会删除其卷。两点边界需要说明只有所选镜像支持的命令才可用——工作流恢复resume、自定义发布与 dedupe 写回都要求 release 内含对应 SDK/CLI 能力仅靠持久化挂载不会凭空增加这些功能runner 本身不会自动调度、重试或跳过阶段。沙箱与生命周期runner 保留了 scanner 的 nonroot 用户、丢弃全部 capabilitiescap_drop: [ALL]、no-new-privileges 以及 seccomp 配置codex-security-seccomp.json 采用默认SCMP_ACT_ERRNO白名单模式并显式放行 Codex 无特权 Bubblewrap user/mount namespace 所需的clone、unshare、mount等系统调用且不覆盖 Codex 的审批或文件系统设置。在限制非特权 user namespace 的宿主上安装既有的 AppArmor profile 并在 runner 的 Compose 命令后追加-f compose.apparmor.yamlsudo install -m 0644 docker/codex-security.apparmor /etc/apparmor.d/codex-security-container sudo apparmor_parser -r -W /etc/apparmor.d/codex-security-container docker compose -f compose.runner.yaml -f compose.apparmor.yaml run --rm codex-security ...该 override 之所以生效是因为 compose.apparmor.yaml 与 runner 示例都使用codex-security服务名。entrypoint 中针对 bulk-scan 的 Landlock 选择逻辑保持不变见 entrypoint.sh检测到apparmor_restrict_unprivileged_userns1且未在codex-security-container (enforce)profile 内运行时自动追加--codex features.use_legacy_landlocktrue源码检查要求宿主支持所选 Codex 沙箱不要为了绕开宿主限制而关闭沙箱。entrypoint 的这些行为由 container-entrypoint.test.ts 等测试覆盖。run --rm只移除已结束的 runner 容器。为后续阶段与重试保留其宿主挂载并使用相同镜像版本与源码路径。备份整个 results 与 state 目录前先停止活跃 runnerfindings 服务单独备份。runner 示例不暴露任何服务端口或 Docker socket。单镜像迁移findings 服务并入共享镜像早期版本中findings-service构建目标与独立的ghcr.io/openai/codex-security-findings发布已合并为共享镜像。源码构建时使用--target scanner或省略--target。迁移步骤更新 compose.findings.yaml将CODEX_SECURITY_FINDINGS_IMAGE设为已发布的ghcr.io/openai/codex-security版本或 digest再拉取并启动服务自定义部署必须继承 Compose 文件中的Node entrypointnode dist/server/index.js、服务器命令、npm 包工作目录/usr/local/lib/node_modules/openai/codex-security以及服务环境HOST0.0.0.0、PORT3000、CODEX_SECURITY_STATE_DIR/state可选CODEX_SECURITY_EMBEDDINGS_URL。按升级与备份指南备份服务。保持相同的 Compose 项目名与挂载在/state的findings-state卷不要执行down --volumes。本次打包变更不会迁移或移动数据库runner 必须保留自己的状态既有已发布镜像与 tag 保持不变。快速上手findings 服务从仓库根目录复制.env.example为.env.env.example 提供OPENAI_API_KEY与可选CODEX_SECURITY_EMBEDDINGS_URL设置 API key 后拉取并启动cp .env.example .env docker compose -f compose.findings.yaml pull docker compose -f compose.findings.yaml up --no-build -d curl -i http://127.0.0.1:3000/v1/findings仅凭compose.findings.yaml加私有.env即可部署无需源码 checkout 或 Node.js 安装。CODEX_SECURITY_FINDINGS_IMAGE默认ghcr.io/openai/codex-security:latest可重复部署时建议指定版本、sha-committag 或 digest。服务启动后自动应用 SQLite 迁移回滚时先停止服务、恢复升级前备份再选择旧镜像 digest旧镜像可能不支持迁移后的数据库。小结从镜像发布、digest 校验到 runner 与 findings 服务的双角色部署codex-security 的容器化方案把单一可信镜像 严格 tag 策略 分离持久化作为核心设计版本不可覆盖、元数据与 digest 强绑定、provenance 公开透明同时通过非 root 用户、cap-drop、no-new-privileges、seccomp 与可选 AppArmor 构成多层沙箱边界。实践中只需记住三条铁律——用 digest 部署、保住/output//state与findings-state卷、绝不把未认证的 findings API 暴露到公网。赞分享应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载相关推荐ProxyPool 的 Docker 部署指南镜像运行、docker-compose 编排与容器化实践ProxyPool 的 Docker 部署指南镜像运行、docker compose 编排与容器化实践 导读 本文围绕 proxy_poolPython P后端网页爬虫网络Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker-compose 编排Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker compose 编排 导读 本文基于 Sanic 官方部署文档完整讲解如何将一后端Web框架QuantDinger 云服务器 Docker 部署实战指南GHCR 镜像、Nginx 反代、HTTPS 与生产排错QuantDinger 云服务器 Docker 部署实战指南GHCR 镜像、Nginx 反代、HTTPS 与生产排错 本指南面向需要把 QuantDinger后端金融科技人工智能AI 应用AI AgentMCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Codex Security 容器镜像发布与 Docker Compose 运行指南：GHCR 镜像、workflow runner 与 findings 服务部署实战
应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载本文围绕 openai/codex-security 仓库的 docker/README.md 展开完整讲解ghcr.io/openai/codex-security容器镜像的发布机制、镜像验证方法、GHCR 管理员初始化流程以及基于 Compose 的 scanner 运行器workflow runner与 findings 服务在同一镜像上的部署、连接与数据持久化方案。读完本文你将掌握如何解析并校验镜像 digest、通过CODEX_SECURITY_IMAGE与CODEX_SECURITY_FINDINGS_IMAGE选择可信镜像、运行容器化批量扫描与去重工作流以及在不丢失状态的前提下安全升级和迁移 findings 服务。镜像发布机制一份镜像两种角色container-release工作流把默认的scannerDocker 构建目标发布为ghcr.io/openai/codex-security。这个单一镜像同时承载两个角色scanner以镜像默认命令运行扫描器 CLIDockerfile 中ENTRYPOINT为入口脚本CMD为--helpfindings 服务以 Node 服务器命令启动见 compose.findings.yaml共享同一镜像但在独立容器、独立状态中运行。发布版本使用 SDK 包版本号、原生 Linuxamd64/arm64构建产物、BuildKit SBOM 与 maximum-mode provenance并附加 GitHub provenance attestation。每个原生镜像在发布多架构 manifest 之前都必须通过 scanner 与 findings 的 API/持久化检查。匿名拉取和 attestation 验证成功后才会推进version、sha-commit与latest三类 tag。稳定版本 tag 一旦发布即不可覆盖——这正是 verify-container-release-version.sh 脚本的职责它在发布前用gh api分页查询 GHCR 包版本若目标 tag 已存在则直接以非零状态拒绝发布。镜像元数据与验证流程发布镜像在每个平台的镜像 labels 以及最终多架构 index 中都带有 OCI 元数据title、description、source、license、vendor、version、source commit、build timestamp、release notes以及固定到该 commit 的 documentation。GHCR 从 index 读取多架构描述而不是仅依赖 Dockerfile labels。工作流为两种架构只生成一次元数据在已发布的候选镜像上验证然后对该确切 digest签名并提升 tag。元数据变更意味着新 digest、新 release已有稳定版本不会被更新。成功发布后workflow summary 会包含 digest、支持的平台、文档链接以及拉取和验证镜像的命令。用下面的命令完成解析 index digest → 校验 → 拉取完整流程把VERSION替换为可用的稳定版本imageghcr.io/openai/codex-security versionVERSION digest$(docker buildx imagetools inspect $image:$version --format {{.Manifest.Digest}}) reference$image$digest docker buildx imagetools inspect $reference --raw | jq .annotations gh attestation verify oci://$reference --repo openai/codex-security docker pull $referencereference形如ghcr.io/openai/codex-securitysha256:...是部署时使用的可信标识。index 会按运行架构自动选择原生amd64或arm64镜像其中unknown/unknown条目对应各平台的 SBOM 与构建 provenance它们不是可运行平台不应被移除。有一点需要特别强调所有 labels、annotations、SBOM 与 provenance 都是公开的切勿在其中放入私有 URL、扫描数据或凭据。BuildKit 的 maximum-mode provenance 会包含 build arguments因此构建凭据应通过 secret mounts 传入而不是 build arguments。从源码构建镜像若要测试未发布的 checkout可先准备通用原生 payload即native/prebuilt下的 8 个平台二进制与共享 notices再本地构建scanner目标docker build --target scanner -t codex-security:local . export CODEX_SECURITY_IMAGEcodex-security:localscanner构建阶段基于node:22-bookworm-slim全局安装 npm 包后依次执行codex-security --version与codex-security bulk-scan --help做冒烟验证随后创建 UID/GID 均为10001的非 root 用户codex-security并预建/input、/output、/state目录见 Dockerfile。GHCR 管理员初始化首次发布前管理员需要完成三件事允许组织级创建包若包不存在则引导创建使用一个经过评审的镜像加非 release tagdocker build --target scanner -t ghcr.io/openai/codex-security:bootstrap . printf %s $CR_PAT | docker login ghcr.io --username YOUR_GITHUB_USER --password-stdin docker push ghcr.io/openai/codex-security:bootstrap docker logout ghcr.io使用具备write:packages权限的 personal access tokenclassic必要时为 SSO 授权绝不将其提交到仓库或传入构建。在包设置中关联openai/codex-security仓库可见性设为Public并在Manage Actions access下授予仓库Write权限。工作流使用GITHUB_TOKEN对于缺失、私有或不可读的包会直接拒绝。登出 GHCR 后应验证docker pull可用。保护container环境为受保护的main分支与已批准的container-v*tag 配置 required reviewers 和 deployment rules允许工作流使用固定的pinnedactions、包写入与 OIDC attestations。若 branch-protection 的 check names 仍引用旧的 release jobs需要一并更新。发布流程合并到main后推送与 SDK 包版本一致的container-vversiontag或在main上手动运行container-release。Release 要求受保护main上有提交pull request 只会构建和测试。若发布失败修复原因后只重跑失败的 job不要覆盖已存在的稳定版本。bootstrap与release-candidate-committag 均非消费者可用版本。Workflow runner以 scanner 镜像运行 CLIcompose.runner.yaml从scanner镜像运行打包好的 CLI它不会启动 findings 服务也不是另一个工作流引擎——命令、输出和退出码都直接透传既有 scanner entrypointcompose.runner.yaml 中默认command: [--help]。在仓库根目录执行以下命令。先准备私有目录并选择宿主用户的 UID/GID以便 runner 写入 bind mountsmkdir -p results state chmod 700 results state export CODEX_SECURITY_USER$(id -u):$(id -g) export CODEX_SECURITY_IMAGEghcr.io/openai/codex-security:latest docker compose -f compose.runner.yaml pull docker compose -f compose.runner.yaml run --rm codex-security login --device-auth无人值守场景可改用OPENAI_API_KEY或CODEX_API_KEY代替登录。Git 认证复用既有的GH_TOKEN/GITHUB_TOKEN与可选的CODEX_SECURITY_GIT_HOST设置——entrypoint 脚本会据此注入git config把githost:重写为 HTTPS 并挂接 git-credential.sh 凭据助手。只传入 runner 需要的凭据findings 服务的 embedding 凭据单独配置。可重复部署建议在CODEX_SECURITY_IMAGE中使用具体版本或 digest。持久化目录设计runner 依赖两个宿主目录由CODEX_SECURITY_RESULTS与CODEX_SECURITY_STATE指定默认./results与./state映射关系如下容器路径持久化内容/output扫描产物及存放在此的源码 checkout/output/.codex-security-stateCLI 扫描历史与 workbench 数据库/stateCodex 登录态与配置三个位置在替换 runner 时都要保留。已批准的源码 checkout 也应保持在同一容器路径便于后续源码复审。例如把 checkout 放在results/repository下然后扫描它并把产物输出到 checkout 之外docker compose -f compose.runner.yaml run --rm codex-security \ scan /output/repository --output-dir /output/scans/run-001 --headless已有 checkout 也可以用run --volume /absolute/repository:/input/repository额外 bind-mount每个需要源码的阶段都要重复挂载。注意把宿主扫描的文件搬进这些目录不会改写其已保存状态中的绝对路径——要么在 runner 内完成扫描要么保留原始路径。绝不要把 runner 的 workbench 数据库或 Codex home 与 findings 服务的/state卷混用。连接 findings 服务独立托管的服务可通过既有--findings-url传入其可达的 base URL。注意容器内 loopback 地址指向 runner 自身而不是 Docker 宿主或其它容器。findings API 没有内置认证应使用私有网络或认证 TLS 代理不得把未认证的 API 暴露到公网。同引擎部署时把服务作为独立 Compose 项目启动docker compose -p findings -f compose.findings.yaml up -d保存仅含网络配置的 override 为compose.runner.local.yamlnetworks: default: external: true name: findings_default然后以不同项目名在该既有网络上运行 runner。服务即使宿主端口仅绑定 loopback也可通过 Compose DNS 名称访问docker compose -p runner -f compose.runner.yaml -f compose.runner.local.yaml \ run --rm codex-security dedupe --scan SCAN_ID \ --findings-url http://findings:3000 --jsonSCAN_ID取自已完成扫描首次导入 findings 时需携带匹配的 repository ID用scan-manifest.json中的scan.target.targetId详见 findings 服务指南。远端服务则省略 network override、直接给 URL。停止或替换 runner 不会停止服务也不会删除其卷。两点边界需要说明只有所选镜像支持的命令才可用——工作流恢复resume、自定义发布与 dedupe 写回都要求 release 内含对应 SDK/CLI 能力仅靠持久化挂载不会凭空增加这些功能runner 本身不会自动调度、重试或跳过阶段。沙箱与生命周期runner 保留了 scanner 的 nonroot 用户、丢弃全部 capabilitiescap_drop: [ALL]、no-new-privileges 以及 seccomp 配置codex-security-seccomp.json 采用默认SCMP_ACT_ERRNO白名单模式并显式放行 Codex 无特权 Bubblewrap user/mount namespace 所需的clone、unshare、mount等系统调用且不覆盖 Codex 的审批或文件系统设置。在限制非特权 user namespace 的宿主上安装既有的 AppArmor profile 并在 runner 的 Compose 命令后追加-f compose.apparmor.yamlsudo install -m 0644 docker/codex-security.apparmor /etc/apparmor.d/codex-security-container sudo apparmor_parser -r -W /etc/apparmor.d/codex-security-container docker compose -f compose.runner.yaml -f compose.apparmor.yaml run --rm codex-security ...该 override 之所以生效是因为 compose.apparmor.yaml 与 runner 示例都使用codex-security服务名。entrypoint 中针对 bulk-scan 的 Landlock 选择逻辑保持不变见 entrypoint.sh检测到apparmor_restrict_unprivileged_userns1且未在codex-security-container (enforce)profile 内运行时自动追加--codex features.use_legacy_landlocktrue源码检查要求宿主支持所选 Codex 沙箱不要为了绕开宿主限制而关闭沙箱。entrypoint 的这些行为由 container-entrypoint.test.ts 等测试覆盖。run --rm只移除已结束的 runner 容器。为后续阶段与重试保留其宿主挂载并使用相同镜像版本与源码路径。备份整个 results 与 state 目录前先停止活跃 runnerfindings 服务单独备份。runner 示例不暴露任何服务端口或 Docker socket。单镜像迁移findings 服务并入共享镜像早期版本中findings-service构建目标与独立的ghcr.io/openai/codex-security-findings发布已合并为共享镜像。源码构建时使用--target scanner或省略--target。迁移步骤更新 compose.findings.yaml将CODEX_SECURITY_FINDINGS_IMAGE设为已发布的ghcr.io/openai/codex-security版本或 digest再拉取并启动服务自定义部署必须继承 Compose 文件中的Node entrypointnode dist/server/index.js、服务器命令、npm 包工作目录/usr/local/lib/node_modules/openai/codex-security以及服务环境HOST0.0.0.0、PORT3000、CODEX_SECURITY_STATE_DIR/state可选CODEX_SECURITY_EMBEDDINGS_URL。按升级与备份指南备份服务。保持相同的 Compose 项目名与挂载在/state的findings-state卷不要执行down --volumes。本次打包变更不会迁移或移动数据库runner 必须保留自己的状态既有已发布镜像与 tag 保持不变。快速上手findings 服务从仓库根目录复制.env.example为.env.env.example 提供OPENAI_API_KEY与可选CODEX_SECURITY_EMBEDDINGS_URL设置 API key 后拉取并启动cp .env.example .env docker compose -f compose.findings.yaml pull docker compose -f compose.findings.yaml up --no-build -d curl -i http://127.0.0.1:3000/v1/findings仅凭compose.findings.yaml加私有.env即可部署无需源码 checkout 或 Node.js 安装。CODEX_SECURITY_FINDINGS_IMAGE默认ghcr.io/openai/codex-security:latest可重复部署时建议指定版本、sha-committag 或 digest。服务启动后自动应用 SQLite 迁移回滚时先停止服务、恢复升级前备份再选择旧镜像 digest旧镜像可能不支持迁移后的数据库。小结从镜像发布、digest 校验到 runner 与 findings 服务的双角色部署codex-security 的容器化方案把单一可信镜像 严格 tag 策略 分离持久化作为核心设计版本不可覆盖、元数据与 digest 强绑定、provenance 公开透明同时通过非 root 用户、cap-drop、no-new-privileges、seccomp 与可选 AppArmor 构成多层沙箱边界。实践中只需记住三条铁律——用 digest 部署、保住/output//state与findings-state卷、绝不把未认证的 findings API 暴露到公网。赞分享应用安全漏洞扫描AI 应用【免费下载链接】codex-securityOpenAIs Codex Security CLI and TypeScript SDK for finding, validating, and fixing security vulnerabilities. npm: https://www.npmjs.com/package/openai/codex-security项目地址https://gitcode.com/gh_mirrors/co/codex-security点击查看免费下载相关推荐ProxyPool 的 Docker 部署指南镜像运行、docker-compose 编排与容器化实践ProxyPool 的 Docker 部署指南镜像运行、docker compose 编排与容器化实践 导读 本文围绕 proxy_poolPython P后端网页爬虫网络Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker-compose 编排Sanic 应用 Docker 化部署实战镜像构建、容器运行与 docker compose 编排 导读 本文基于 Sanic 官方部署文档完整讲解如何将一后端Web框架QuantDinger 云服务器 Docker 部署实战指南GHCR 镜像、Nginx 反代、HTTPS 与生产排错QuantDinger 云服务器 Docker 部署实战指南GHCR 镜像、Nginx 反代、HTTPS 与生产排错 本指南面向需要把 QuantDinger后端金融科技人工智能AI 应用AI AgentMCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考