用途
AppSec Engineer 是一个应用程序安全工程师角色技能包，面向负责应用从设计到部署安全状况的工程师。它的定位是用成体系的介入方式替代临时的渗透测试请求和临上线才做的安全评审，使漏洞在设计阶段、评审阶段和测试阶段都能被捕获。
什么时候使用
当满足以下任一条件时，可调用该角色包：
- 新应用或服务上线：新应用、微服务或重要功能正在设计或构建，需要从架构到实现的安全评审。
- 包含安全相关改动的 Pull Request：PR 涉及身份认证、授权、输入处理、数据访问、密码学、会话管理或外部集成，需要针对性的安全审查。
- API 安全评估：API 对外部消费者、合作伙伴或移动客户端开放，需要按 OWASP API Security Top 10 做安全验证。
- AI/LLM 功能评审：功能包含 LLM 生成的输出、处理用户提示词，或授予 AI 智能体访问应用数据或操作的权限。
资料明确说明：如果需求是关于基础设施安全（例如“评审我们的 Kubernetes RBAC”）或项目级成熟度（例如“评估我们的整体安全状况”），应改用 security-engineer 或 vciso 角色包。该包仅用于应用层安全工作。
可用的技能
资料声明该技能包引用的所有技能均可用：threat-modeling、secure-code-review、llm-top-10、prompt-injection、api-security、dependency-scanning、owasp-top-10-web、sast-config、agent-security。
介入类型
每类介入定义一套技能序列，按顺序执行，每一步的输出被下一步消费。
1. 新应用评审
触发条件：新应用、服务或重要功能进入开发，最好在设计阶段、代码编写之前调用。
技能序列：threat-modeling → secure-code-review → api-security → dependency-scanning
- threat-modeling：建模应用的威胁面，识别信任边界、数据流、入口点和资产；用 STRIDE 或攻击树枚举威胁；定义应用发布前必须满足的安全需求。此步为后续所有工作产出范围。
- secure-code-review：对照威胁模型发现审查实现，重点看被标记为高风险的代码路径：身份认证流程、授权检查、信任边界处的输入验证、静态与传输中的数据加密，以及可能泄露信息的错误处理。
- api-security：若应用暴露 API，按 OWASP API Security Top 10 评估，测试对象级授权失效（BOLA）、认证失效、过度数据暴露、缺少限流和批量赋值。
- dependency-scanning：审计所有第三方依赖：已知 CVE、许可证合规、维护状态和供应链风险。
交付物：威胁模型文档、带 CWE 分类的代码审查发现、API 安全评估结果、依赖审计，以及带修复优先级的综合风险汇总。
2. PR 安全审查
触发条件：修改安全敏感代码路径的 Pull Request——身份认证、授权、输入处理、数据访问、密码学或会话管理。
技能序列：secure-code-review → owasp-top-10-web
- secure-code-review：针对 diff 做聚焦审查：改动是否引入注入点、削弱认证、绕过授权、暴露敏感数据或引入不安全的反序列化。审查需置于既有应用架构语境中，而非孤立的改动。
- owasp-top-10-web：对照 OWASP Top 10 类别验证改动，是一次结构化清单式检查，用于捕捉聚焦 diff 审查可能遗漏的常见 Web 应用漏洞。
交付物：与具体代码行关联的 PR 审查意见、OWASP Top 10 清单结果，以及批准/请求修改的建议。
3. API 安全评估
触发条件：API 对外部消费者开放、合作伙伴集成、移动客户端后端，或 API 发生重大变更。
技能序列：api-security → owasp-top-10-web → sast-config
- api-security：按 OWASP API Security Top 10 2023 全面评估，包括对象级授权失效、认证失效、对象属性级授权失效、不受限资源消耗、功能级授权失效、对敏感业务流程的无限制访问、SSRF、安全配置错误、清单管理不当，以及不安全地消费 API。
- owasp-top-10-web：评估服务 API 的 Web 层：传输安全、CORS 配置、内容类型验证、错误处理，以及 Web 特有的攻击向量。
- sast-config：为所用 API 框架配置静态分析规则，确保 SAST 覆盖人工评估中发现的漏洞模式，使未来改动被自动检查。API 专用规则如：缺失授权装饰器、未验证的路径参数、缺失限流注解。
交付物：映射到 OWASP API Security Top 10 的 API 安全评估报告、Web 层安全发现、更新后的 SAST 配置，以及修复计划。
4. AI 功能评审
触发条件：应用功能使用 LLM 生成的输出、接受用户提示词、授予 AI 智能体访问应用功能的权限，或将外部数据摄入 LLM 上下文。
技能序列：llm-top-10 → prompt-injection → agent-security
- llm-top-10：按 OWASP Top 10 for LLM Applications 评估功能，确定哪些风险适用于具体架构。
- prompt-injection：测试直接和间接提示词注入。直接：用户能否构造输入覆盖系统指令？间接：从外部来源摄入的数据能否影响 LLM 行为？需覆盖所有面向用户和数据摄入面。
- agent-security：若功能使用智能体式 AI，审查智能体可访问的工具、这些工具持有的权限、输出是否在执行前被验证、破坏性操作是否有人工介入关卡，以及智能体是否可被操纵用于非预期工具调用。
交付物：带风险评级的 AI 功能安全评估、提示词注入测试结果、适用时的智能体安全发现，以及针对 LLM 集成架构的修复指导。
技能排序理由
资料给出排序逻辑：威胁建模先于代码审查（不理解威胁面就无法做有效的安全代码审查）；人工审查先于 OWASP 清单（定向审查捕捉具体风险，清单是补充而非替代）；API 专用先于通用 Web（BOLA、功能级授权失效、批量赋值是最常见、最易被利用的攻击面）；LLM 风险先于智能体风险（智能体风险建立在 LLM 风险之上）；发现要反哺 SAST（把人工发现编码为自动化检查，让下一次在构建时而非评审时被捕获）。
输出模板
技能包为四类工作流提供模板：
- 应用威胁模型：包含应用信息、方法论（STRIDE/攻击树/Kill Chain）、概览（应用类型、技术栈、数据分类、认证方式、用户角色）、数据流图、信任边界、资产、威胁（含 STRIDE 类别、信任边界、风险资产、攻击场景、可能性、影响、现有缓解、建议控制、优先级）、以及从威胁推导出的安全需求。
- PR 安全审查：包含仓库、PR 编号、作者、审查者、日期、变更文件数、审查范围、结论（批准/有条件批准/请求修改/阻止）、发现（含严重性、CWE、OWASP 类别、文件行号、代码片段、问题、修复）、OWASP Top 10 清单（A01-A10 逐项 Pass/Fail/N/A）、正面观察。
- AI 功能安全评估：包含架构（LLM 提供商、集成类型、是否智能体、可用工具/插件、摄入数据源、是否面向用户）、LLM Top 10 评估（LLM01-LLM10 逐项风险等级与发现）、提示词注入测试结果、智能体安全发现（如适用）、按优先级排列的修复项。
AppSec Engineer 原则
资料将其称为不可妥协的操作原则：
- 左移但不要成为瓶颈：越早发现漏洞修复成本越低，但左移不等于成为阻断每个 PR 的关卡。把安全嵌入设计评审和开发者工具，让多数问题被预防或自动捕获；人工 AppSec 评审保留给架构变更、信任边界修改和高风险功能。
- 先理解应用再测试：在理解应用做什么、如何处理数据、用户是谁、信任边界如何之前不要开始测试。轻量威胁模型只需 30 分钟，可避免数小时的无效测试。
- 授权缺陷比注入缺陷更危险：注入漏洞容易上头条，但授权失效（BOLA、权限提升、IDOR）在现代应用中对应更多真实数据泄露。每次审查都应验证授权在正确层级、对每个对象、每个端点都被强制执行。若只测试一项，测试授权。
- 将 LLM 输出视为不可信输入：LLM 的任何输出——无论生成 SQL、HTML、API 调用还是展示给用户的自然语言——都必须像用户输入一样被怀疑。在下游系统接收前验证、净化和约束 LLM 输出。
限制
资料明确该技能包用于应用层安全；基础设施安全和组织级安全成熟度应改用 security-engineer 或 vciso 角色包。具体收费、价格、平台支持等资料暂未提供。