sachinsinsinwar/cloud-native-ecommerce

# SecureOps 一个注重实践的 DevSecOps 项目。将一个容器化的电商应用转化为安全的软件供应链：每次 push 都会运行安全检查（密钥扫描、SAST、依赖扫描、容器扫描、无密钥签名、SBOM 证明），并且 Kubernetes 集群会拒绝运行任何无法证明源自此 pipeline 的镜像。 [](https://github.com/sachinsinsinwar/cloud-native-ecommerce/actions/workflows/security-pipeline.yml) ## Pipeline ``` flowchart LR A[Push] --> B[Gitleaks] B --> C[SAST] C --> D[SCA] D --> E[Build] E --> F[Image scan] F --> G[Sign + SBOM] G --> H[Deploy by SHA] H --> I[Kyverno verify] classDef green fill:#1f9d57,stroke:#0f5c33,color:#ffffff classDef start fill:#dfe1e6,stroke:#6b7280,color:#1f2937 class A start class B,C,D,E,F,G,H,I green ``` 每次 push 都会运行此流程。如果任何检查环节失败，构建就会停止。只有通过所有检查环节的镜像才会被构建、扫描、签名和部署。  ## 每次推送时运行的检查 | 阶段 | 工具 | 检查内容 | | :-- | :-- | :-- | | 密钥扫描 | Gitleaks | 未提交任何凭据或密钥 | | SAST | Semgrep | 应用自身代码中的 bug | | SCA | Trivy (filesystem) | 依赖项中已知的 CVE | | 构建 | Docker Buildx，推送至 ghcr.io | 构建并推送以 commit SHA 标记的镜像 | | 镜像扫描 | Trivy (image) | 整个容器（包括基础 OS）中的 CVE | | 签名 + SBOM | Cosign (无密钥) 和 Syft | 对每个镜像进行签名并附带软件物料清单 | | 总结 | GitHub job summary | 在运行页面上提供彩色的 pipeline 视图 | ## 供应链强制执行（核心理念） 签名本身没有任何作用。必须有机制去检查它。因此，集群运行 **Kyverno** 作为准入控制器，并设定一条规则：任何 `ghcr.io/sachinsinsinwar/ecommerce-*` 镜像都必须带有来自此仓库 GitHub Actions workflow 的有效无密钥 Cosign 签名，否则无法启动。 - 由本 pipeline 签名，针对确切的 workflow 身份进行验证，准许接入。 - 未签名，或由任何其他人签名的镜像，将在入口处被拒绝，并提示 `no matching signatures found`。 这将信任边界从“信任注册表中的每个镜像”缩小到了“仅信任由此 pipeline 产生、并由这一确切身份签名的镜像”。  ## 部署与回滚 镜像以 commit SHA 进行标记，因此每次部署都是一个不可变的、有明确名称的版本。部署会设定一个具体的 SHA，绝不使用浮动的 `:latest`，这使得真正的回滚成为可能： ``` kubectl rollout undo deployment/backend -n ecommerce ``` 借助就绪探针和 `maxUnavailable: 0` 的滚动更新，有故障的部署不会导致网站宕机。旧的 pod 会继续提供服务，而新的 pod 无法通过健康检查，发布过程会停滞而不是破坏生产环境，你可以在几秒钟内完成回滚。 ## 架构与技术栈 - **应用：** React + Vite (前端)，Flask + Python (后端)，PostgreSQL，Redis - **注册表：** GitHub Container Registry (ghcr.io) - **集群：** 单节点上的 K3s (AWS Lightsail)，ingress-nginx，搭配 Let's Encrypt 的 cert-manager - **CI/CD：** GitHub Actions - **安全：** Gitleaks, Semgrep, Trivy, Cosign, Syft, Kyverno - **边缘：** Cloudflare ## 值得关注的工程决策 这些是刻意做出的权衡，而非默认设置。 - **精准修复 vs 全局 OS 补丁。** 在实时运行的服务器上，你通常会避免使用 `apt upgrade`，因为它会改变运行中的应用下层的所有内容。但在镜像构建内部这是安全的，因为镜像在部署前会被重新构建和扫描。构建时使用全局 OS 补丁可以一次性清除基础层的 CVE，而不必逐个包去修复。 - **已记录的风险接受。** 有少数 CVE 存在于运行中的应用从未调用过的、仅用于构建的 Python 工具中。与其让它们阻塞 pipeline，不如将它们列在 `.trivyignore` 中并附上书面理由。这就是 VEX 的理念：说明为什么接受一个发现，而不是默默地忽略它。 - **已停止维护（生命周期结束）的基础镜像。** 前端此前使用的是一个不再获得安全补丁的 Alpine 版本，因此其 CVE 永远无法被修复。它已被迁移至受支持的基础镜像并进行了修补。 - **通过摘要而非标签进行签名和验证。** 标签是会变动的，而摘要永远对应那一个确切的镜像。签名和准入均基于摘要进行。 - **限定范围的准入策略。** Kyverno 规则仅匹配此项目的两个镜像。所有其他镜像（数据库、上游工具、其他项目）均不受影响。刻意将爆炸半径降至最低。 - **故障开放 vs 故障关闭。** 在这个单节点集群上，策略采用故障开放模式，因此 Kyverno 的宕机不会导致集群无法进行部署。在生产环境中，当 Kyverno 以高可用模式运行时，你会采用故障关闭模式。 ## 路线图 - 针对运行中的应用进行 DAST (OWASP ZAP) - 使用 Falco 和 Trivy Operator 进行运行时安全防护 - 使用 Argo CD 进行 GitOps 交付，使部署变成一次 commit，回滚变成一次带有完整审计追踪的 git revert ## 在线演示 - 应用：https://ecommerce.sachininfo.xyz - API：https://ecommerceapi.sachininfo.xyz

标签：AI应用开发, DevSecOps, 上游代理, 子域名突变, 安全软件供应链, 搜索引擎查询, 测试用例, 电商应用, 请求拦截, 逆向工具, 镜像签名