安全扫描类应用的容器化编排需以“可信输入、可控执行、可靠输出”为核心，通过docker compose实现资源限制、只读卷挂载、非root运行、网络隔离及服务依赖控制，并兼顾cve联网访问、selinux兼容性与健康检查等落地细节。
明确目标：安全扫描类应用的容器化编排逻辑
用 Docker Compose 编排安全扫描工具，核心不是“跑起来”，而是让扫描能力可复用、可隔离、可集成。典型场景包括：CI/CD 流水线中自动镜像扫描、多目标并行 Web 漏洞探测、扫描结果持久化与 API 对接、以及与 GitLab 或 Harbor 等平台联动。这些都需要在 compose 文件里体现网络策略、卷挂载、环境变量控制和启动依赖关系。
关键配置项：必须写进 docker-compose.yml 的安全要素
一份适配原生安全扫描的 docker-compose.yml 不是简单罗列 services，而要围绕“可信输入、可控执行、可靠输出”设计：
-
资源限制必须显式声明：避免单个扫描任务耗尽宿主机 CPU 或内存。例如在 service 下添加：
deploy:<br> resources:<br> limits:<br> cpus: '1.5'<br> memory: 2g
-
扫描输入需通过 volume 安全挂载：不推荐用 build-time COPY 加载字典或配置，应挂载只读卷。例如：
volumes:<br> - ./scans/config.yaml:/app/config.yaml:ro<br> - ./wordlists:/app/wordlists:ro
-
输出结果强制落盘 + 权限收敛：扫描日志和报告写入命名卷或绑定挂载路径，并设置非 root 用户运行。例如：
volumes:<br> - scan-results:/app/reports<br>user: "1001:1001"
-
网络隔离与服务发现：多个扫描器（如 Trivy + Gobuster + NodeJSScan）共存时，用自定义 bridge 网络 + internal 网络策略防止误扫自身服务：
networks:<br> scan-net:<br> driver: bridge<br> internal: true
实战示例：Trivy + HarborGuard 协同扫描流水线
假设你希望每次推送镜像到私有 Registry 后，自动触发漏洞扫描并同步结果到 HarborGuard Web 界面。docker-compose.yml 可这样组织：
- 定义 registry 服务：启用 v2 API，暴露 5000 端口，挂载证书和存储卷
- 定义 harbor-guard 服务：使用官方镜像，挂载 PostgreSQL 数据卷，开放 3000 端口，通过环境变量配置数据库连接和默认扫描超时
- 定义 trivy-scan-job 服务：基于 trivy:latest 镜像，设为
restart: "no"，通过 depends_on 关联 registry 和 harbor-guard，启动命令为：sh -c "trivy image --format json --output /scans/report.json myapp:latest && curl -X POST http://harbor-guard:3000/api/scans -H 'Content-Type: application/json' -d @/scans/report.json" - 所有服务共享一个
scan-data卷用于临时存放 report.json，且该卷设为external: false保证生命周期跟随 compose stack
避坑提醒：容易被忽略但影响落地的细节
很多部署失败不是因为语法错误，而是违反了容器安全扫描的运行前提：
- Trivy、Grype 等工具需要访问 CVE 数据库，容器内必须能解析公网域名（如 nvd.nist.gov），若使用 internal 网络，需额外配置 DNS 或允许特定 outbound 流量
- 挂载 host 路径时，确保 SELinux 或 AppArmor 策略未阻止容器读取（常见于 CentOS/RHEL），可加
security_opt: ["label=disable"]临时验证 - HarborGuard 或 OpenVAS 类带 Web 界面的工具，首次启动会初始化数据库，需在 compose 中用
healthcheck控制依赖顺序，不能仅靠 depends_on - 扫描结果若含敏感路径（如 /etc/shadow 哈希误报），需在 config.yaml 中配置 ignore规则或启用 --skip-files 参数，避免日志泄露
