jeremiahredden/appsec-reference-architecture

GitHub: jeremiahredden/appsec-reference-architecture

一个实践导向的应用安全参考工具包,将威胁建模、DevSecOps 管道、OWASP 修复与云安全模式整合为可运行的工程工件。

Stars: 0 | Forks: 0

# 应用安全参考架构 ![AppSec Pipeline](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/189166f274222807.svg) ![IaC Scan](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/725a1bd474222808.svg) ![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg) ![Maintained](https://img.shields.io/badge/Maintained-yes-green.svg) ### 将安全嵌入现代工程组织的实践者工具包 **Jeremiah Redden** | 高级 AI/应用安全架构师 | CISSP | [github.com/jeremiahredden](https://github.com/jeremiahredden) 本仓库是一个活用的参考工具包,涵盖应用安全架构、DevSecOps 管道设计、威胁建模、OWASP 修复、AI/LLM 安全以及云安全模式。内容面向安全架构师和工程师,提供实用的、有观点的指导,而非合规检查清单。 材料反映了我实际开展合作的方式:足够轻量,让工程团队在下个季度仍会与我沟通;足够严谨,让落地实施的控制措施能通过审计。每个模板都已在生产环境中使用。每个工作示例都经过匿名化处理,源自真实系统。 ## 实时管道 该仓库在每次推送到 `main` 分支以及每个拉取请求时运行一个实时的 GitHub Actions 应用安全管道。与 [`devsecops-pipeline/`](./devsecops-pipeline/) 中记录的相同工作流处于活动状态——你可以观察其运行、检查发现结果,并将其复制到你的项目中。 该管道扫描一个故意存在漏洞的参考应用([`demo-app/`](./demo-app/)),以便“安全”选项卡始终包含真实、可复现的发现。它覆盖了整个技术栈: - **Semgrep** — 对 `demo-app/` 进行 SAST 扫描,使用托管的 `p/default` 规则集以及 [`devsecops-pipeline/semgrep-rules/custom-rules.yaml`](./devsecops-pipeline/semgrep-rules/custom-rules.yaml) 中的自定义规则 - **pip-audit** — 对 `demo-app/python-api/requirements.txt` 进行 Python SCA 扫描 - **npm audit** — 对 `demo-app/node-api/` 进行 Node SCA 扫描 - **Gitleaks** — 扫描整个 Git 历史中的密钥,使用 [`.gitleaks.toml`](./.gitleaks.toml) 中的范围化允许列表,确保演示密钥不会掩盖真实密钥 - **Checkov** — 对 Terraform、CloudFormation、Kubernetes、Dockerfile 和 ARM 进行 IaC 扫描 **查看位置:** - 管道定义 → [`.github/workflows/appsec-pipeline.yml`](./.github/workflows/appsec-pipeline.yml) - 故意扫描目标 → [`demo-app/README.md`](./demo-app/README.md) - 实时发现 → **Security** 选项卡 → **Code scanning**(Semgrep 和 Checkov 的 SARIF 数据会自动汇入此处) - 破坏构建策略 → [`devsecops-pipeline/policy-as-code/break-build-policy.md`](./devsecops-pipeline/policy-as-code/break-build-policy.md) 演示应用在每个文件顶部标注了 `EDUCATIONAL USE ONLY`。每个漏洞都注释为 `# VULNERABILITY: — intentional for pipeline demonstration`,并配有对应的安全版本。如果你想了解每个工具在脆弱目标上能捕获什么,以及修复后的样子,这个文件夹就是你要查阅的工件。 ## 目录 - **[threat-modeling/](./threat-modeling/)** — STRIDE 模板、一个实际医疗 API 示例,以及运行 60–90 分钟威胁建模会议的引导指南,适用于工程团队。 - **[secure-code-review/](./secure-code-review/)** — 手动审查流程指南、Python 与 JavaScript 检查清单,以及涵盖注入、认证、加密、反序列化、原型污染和密钥泄露的脆弱/安全代码配对示例。 - **[devsecops-pipeline/](./devsecops-pipeline/)** — 有意见倾向的 CI/CD 管道,包含 SAST、SCA、密钥扫描、IaC 扫描和策略即代码门控。包含可工作的 GitHub Actions 工作流、自定义 Semgrep 规则和文档化的破坏构建策略。 - **[owasp-remediation-playbooks/](./owasp-remediation-playbooks/)** — 对应 OWASP Top 10 2021 类别(A01–A10)的修复手册。每个类别涵盖利用场景、手动与自动检测、配对脆弱/安全修复、pytest/Jest 测试以锁定修复,以及覆盖 HIPAA、SOC 2、NIST CSF 2.0 和 PCI-DSS v4.0 的合规映射表。 - **[compliance-control-mapping/](./compliance-control-mapping/)** — HIPAA 安全规则、SOC 2 信任服务标准与 NIST CSF 2.0 按行映射到应用安全控制,包含实施示例和证据工件。包含 NIST CSF 成熟度模型(初始 → 管理 → 定义 → 优化)以及 PHI 在日志中的修复专用章节。 - **[architecture-patterns/](./architecture-patterns/)** — 有意见倾向的安全 API 设计、OAuth2/OIDC 流程、Saas 的零信任架构,以及使用 Istio 的 mTLS 服务网格的架构模式。包含 ASCII 图、注解配置和采用路线图,而非参考手册式介绍。 - **[ai-llm-security/](./ai-llm-security/)** — LLM 支持应用的威胁模型、提示注入纵深防御、代理隔离与权限层级、RAG 管道安全,以及针对每个 OWASP LLM Top 10 (2025) 类别的开发者修复手册。包含实际医疗助理的 STRIDE 示例和加固后的 Python/JavaScript 模式。 - **[cloud-security/](./cloud-security/)** — AWS 与 Azure 安全参考架构、最小权限 IAM(含可部署的 SCP)、Entra ID 模式、Defender for Cloud 修复手册,以及多云 CSPM 和零信任指导。对原生优先采用持明确观点,并清晰说明何时值得引入第三方工具。 - **incident-response/** *(即将推出)* — 常见应用安全事件类的运行手册:泄露凭证、暴露 S3 存储桶、依赖项妥协、提示注入逃逸。 ## 如何使用该仓库 **如果你是安全架构师**,可直接套用威胁建模模板和引导指南。它们设计为可 fork 到 Confluence/Notion 等协作空间,轻微定制客户信任边界后即可在当周使用。 **如果你是安全工程师**,应从 DevSecOps 管道参考入手。复制 GitHub Actions 工作流,调整严重性阈值以适应组织风险偏好,并在争论最佳工具之前先交付基线。 **如果你是工程团队负责人**,采用“默认安全”实践时,请结合当前代码库阅读 OWASP 修复内容。每个发现都对应可在单个冲刺中完成的修复,而非六个月的重写。 **如果你是招聘经理**,用于评估我的工作成果(威胁模型、事件运行手册、安全架构模式)比简历更能反映实际交付。优先阅读这些内容。 ## 哲学 所有内容受三条原则驱动: **1. 安全应让团队更快,而非更慢。** 一个在 40 分钟内因误报而阻断部署的管道门,不是安全控制,而是团队会绕过的生产力税。正确的安全自动化应缩短反馈回路:在开发者 IDE 中快速失败,在 CI 中清晰失败,并为工程师提供修复而非 PDF。我优先选择能减少总体摩擦的控制,即使这意味着接受残余风险。 **2. 正确的控制是那个真正被实施的控制。** 幻灯片上完美的控制不如周一在生产环境中运行的 80% 控制。我更愿意在本 sprint 落地一个范围可控的 WAF 规则并持续迭代,也不愿花费一个季度进行从未发布的全面重写。这不是对粗放的许可,而是对交付的偏好。在记录模式时,我会同时注明快速交付的降级版本与最终的金标准版本。 **3. 每个发现都必须提供工程师在当前 sprint 内可执行的修复。** 以“改进认证姿态”结尾的威胁模型已经失败;以“在第 47 个 sprint 结束前,将共享服务账户的 JWT 签名密钥轮换为基于 KMS 的每服务密钥,并指派平台团队,在 JIRA-8821 中跟踪”为结尾的发现才算成功。没有负责人、截止日期和具体技术指导的发现最终只会成为文档垃圾。我在编写本仓库的每个模板和示例时都遵循这一标准。 **4. 仅存在于文档中的安全控制并不存在。展示你的工作。** 策略幻灯片、架构演示和控制矩阵只是意图的证据,而非保护的证据。该仓库中的管道存在正是为了这一点——它将 `devsecops-pipeline/` 文件夹从提案转变为运行中的控制。只要可能,我就会将主张置于可运行的代码之前。没有执行点的“零信任架构”、没有 deny 语句的“最小权限 IAM”、没有失败构建的“安全 SDLC”——这些只是表演。我编写本仓库的标准是:每个架构主张都必须有评审者可执行的工件作为支撑。 ## 许可证与署名 除非另有说明,本仓库中的所有内容均在 MIT 许可下发布。模板和手册可自由使用、修改和改编,包括在商业合作和客户交付物中。署名虽非必需,但备受赞赏。 如果你发现有用的内容,欢迎提出 issue、在 LinkedIn 上联系我,或提交带有改进的 pull request。
标签:AI安全, AWS, Azure, Chat Copilot, CI/CD安全, DevSecOps, DPI, EC2, GCP, IaC, Llama, SAST, Semgrep, Web安全, Web截图, WordPress安全扫描, 上游代理, 可复用模板, 大语言模型安全, 威胁建模, 子域名突变, 安全代码审查, 安全右移, 安全实践, 安全左移, 安全开发生命周期, 安全架构, 安全治理, 容器安全, 数据可视化, 机密管理, 生产环境安全, 盲注攻击, 蓝队分析, 逆向工具