---
title: "Security Engineer Agent Personality"
type: source
tags: [agent-personality, security, application-security]
sources: []
last_updated: 2026-05-01
---

## Source File
- [[Agent/agency-agents/engineering/engineering-security-engineer.md]]

## Summary（用中文描述）
- 核心主题：定义一个专注于应用安全工程的 AI Agent 人格，具备威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路能力
- 问题域：现代 Web 应用、API、云原生应用的安全防护，覆盖 OWASP Top 10、CWE Top 25、API 安全、云安全、供应链安全等广泛领域
- 方法/机制：采用对抗性思维框架（STRIDE 分析）、防御深度策略（defense-in-depth）、零信任架构；在 SDLC 各阶段集成安全；通过 SAST/DAST/SCA/secrets 检测构建 CI/CD 安全门禁
- 结论/价值：该 Agent 以攻击者视角思考，以工程师方式防御，通过威胁建模前置识别风险、通过分层防护降低攻击面、通过自动化检测实现安全左移

## Key Claims（用中文描述）
- Security Engineer Agent 通过将安全集成到设计→实现→测试→部署→运营的全生命周期，实现风险前置发现
- 所有用户输入均视为敌对输入，必须在每个信任边界（客户端、API 网关、服务、数据库）进行验证和清理
- 默认拒绝原则（Default Deny）：在访问控制、输入验证、CORS、CSP 中优先使用白名单而非黑名单
- 防御深度原则：永远不依赖单一保护层，假设任何一层都可能被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的多层叠加实现真正安全
- 零信任架构：以最小权限为原则，结合微隔离，实现每次访问均需验证
- 供应链安全：通过 SBOM 生成与监控、CVE 审计、包完整性校验（校验和、签名、lock 文件）、依赖混淆/typosquatting 攻击检测，构建可信依赖链

## Key Quotes
> "You think like an attacker to defend like an engineer." — Security Engineer 的核心哲学定位
> "Security is a spectrum, not a binary. You prioritize risk reduction over perfection, and developer experience over security theater." — 安全的本质是风险管理，而非追求完美
> "Every finding must include a severity rating, proof of exploitability, and concrete remediation with code." — 安全发现必须包含严重等级、可利用性证明和具体修复代码
> "No hardcoded credentials, no secrets in logs, no secrets in client-side code, no secrets in environment variables without encryption." — 密钥管理四条铁律
> "The best security control is one that developers adopt willingly because it makes their code better, not harder to write." — 安全与开发者体验的平衡哲学

## Key Concepts
- [[ThreatModeling]]：通过 STRIDE 框架（Spoofing/Tampering/Repudiation/Information Disclosure/DoS/Elevation of Privilege）对每个组件进行系统性威胁分析
- [[OWASP Top 10]]：2021+ 版本的十大 Web 应用安全风险（注入、XSS、身份认证失效、敏感数据泄露、XXE、访问控制失效、安全配置错误、脚本插入、逆向工程、日志监控缺失）作为代码审查和漏洞评估的基准清单
- [[DefenseInDepth]]：多层防御策略，假设任何单层均可被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的叠加实现纵深防护
- [[ZeroTrust Architecture]]：永不信任、始终验证的架构范式，以最小权限访问控制和微隔离为技术核心
- [[CVSS 3.1]]：通用漏洞评分系统，用于标准化漏洞严重等级（Critical/High/Medium/Low/Informational）评估
- [[SAST/DAST/SCA]]：静态应用安全测试（代码层面）、动态应用安全测试（运行时）、软件组成分析（依赖层面）三位一体的自动化安全检测体系
- [[RBAC/ABAC/ReBAC]]：基于角色的访问控制、基于属性的访问控制、基于关系的访问控制三种授权模型，根据应用需求匹配合适的访问控制方案
- [[SupplyChainSecurity]]：SBOM 生成与监控、依赖 CVE 审计、混淆攻击检测、可复现构建的供应链全链条安全管理
- [[SecretsManagement]]：密钥的全生命周期管理，包括轮换策略，推荐工具包括 HashiCorp Vault、AWS Secrets Manager、SOPS
- [[IncidentResponse]]：安全事件的分类、遏制、根因分析和修复建议的完整事件响应流程

## Key Entities
- [[Semgrep]]：开源 SAST 工具，用于规则驱动的代码安全扫描
- [[Trivy]]：容器和依赖漏洞扫描工具，支持 CRITICAL/HIGH 级别阻断
- [[Gitleaks]]：Git 提交中的密钥和敏感信息检测工具
- [[HashiCorp Vault]]：企业级密钥管理与轮换平台
- [[AWS Secrets Manager]]：AWS 原生的密钥管理服务
- [[OAuth 2.0 + PKCE]]：现代认证授权协议组合，PKCE 防止授权码拦截攻击
- [[WebAuthn/Passkeys]]：无密码认证标准，基于公钥加密消除密码泄露风险
- [[STRIDE]]：微软提出的威胁建模框架，六个维度系统性评估系统威胁

## Connections
- [[Engineering-SRE]] ← overlaps_with ← [[SecurityEngineer]]（均涉及云安全、基础设施安全监控和事件响应）
- [[Engineering-Code-Reviewer]] ← extends ← [[SecurityEngineer]]（代码审查中必须集成安全视角）
- [[Testing-Accessibility-Auditor]] ← parallels ← [[SecurityEngineer]]（均通过系统性测试流程发现应用问题）
- [[零信任架构]] ← is_a_concept_of ← [[SecurityEngineer]]（零信任是安全架构设计的核心理念）

## Contradictions
- 与 [[Engineering-SRE]] 存在视角差异：
  - 冲突点：SRE 以可用性为优先，安全工程师以安全性为优先，两者对"故障时的默认行为"存在权衡分歧
  - 当前观点（Security Engineer）：fail securely — 错误不得泄露堆栈跟踪、内部路径、数据库 schema 或版本信息
  - 对方观点（Engineering-SRE）：fail loudly — 快速失败以减少 MTTR，依赖完善的监控告警而非隐藏错误细节
  - 协调方案：在生产环境 fail securely + 结构化日志输出给监控系统；在开发/测试环境可保留详细错误信息以加速调试