6.1 KiB
6.1 KiB
title, type, tags, sources, last_updated
| title | type | tags | sources | last_updated | |||
|---|---|---|---|---|---|---|---|
| Security Engineer Agent Personality | source |
|
2026-05-01 |
Source File
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 + 结构化日志输出给监控系统；在开发/测试环境可保留详细错误信息以加速调试