Security Architect by daffy0208/ai-dev-standards
npx skills add https://github.com/daffy0208/ai-dev-standards --skill 'Security Architect'安全架构师是一个整合性技能,涵盖完整的安全生命周期:威胁建模、安全设计原则、安全编码实践和法规遵从性。它确保安全从一开始就被集成,而不是在最后才附加。
整合自:
在以下情况下使用安全架构师:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
S - 欺骗(身份验证)
T - 篡改(完整性)
R - 抵赖(可问责性)
I - 信息泄露(机密性)
D - 拒绝服务(可用性)
E - 权限提升(授权)
步骤 1:识别资产
步骤 2:识别信任边界
步骤 3:对每个边界应用 STRIDE 对于每个边界,提问:
步骤 4:评估风险
Risk = Likelihood × Impact
Likelihood:
- High (likely to occur)
- Medium (may occur)
- Low (unlikely to occur)
Impact:
- Critical (data breach, financial loss, legal liability)
- High (significant damage, downtime)
- Medium (limited damage, temporary disruption)
- Low (minimal impact)
Risk Level:
- Critical: Immediate action required
- High: Address before launch
- Medium: Address post-launch
- Low: Monitor, may accept risk
步骤 5:定义缓解措施 对于每个威胁,记录:
1. 纵深防御 多层安全控制。如果一层失效,其他层仍能提供保护。
示例:
2. 最小权限 用户/系统仅拥有所需的最小权限。
示例:
3. 零信任 永不信任,始终验证。即使是内部网络也不可信。
示例:
4. 默认安全 默认配置是安全的。用户必须选择启用安全性较低的选项。
示例:
5. 安全失败 发生错误时,以不损害安全性的方式失败。
示例:
身份验证:
授权:
@requireRole('admin')数据保护:
API 安全:
秘密管理:
A01:访问控制缺陷
/user/123 → /user/456如何检测:
// BAD: No authorization check
app.get('/api/users/:id', (req, res) => {
const user = db.users.findById(req.params.id)
res.json(user) // Anyone can see any user!
})
// GOOD: Check ownership
app.get('/api/users/:id', authMiddleware, (req, res) => {
const requestedId = req.params.id
const currentUserId = req.user.id
if (requestedId !== currentUserId && !req.user.isAdmin) {
return res.status(403).json({ error: 'Forbidden' })
}
const user = db.users.findById(requestedId)
res.json(user)
})
A02:加密机制失效
如何检测:
// BAD: Plaintext password
const user = { email, password: req.body.password }
db.users.create(user)
// GOOD: Hash with bcrypt
const bcrypt = require('bcrypt')
const hashedPassword = await bcrypt.hash(req.body.password, 10)
const user = { email, password: hashedPassword }
db.users.create(user)
A03:注入
如何检测:
// BAD: SQL Injection
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`
db.query(query) // Attacker can send: ' OR '1'='1
// GOOD: Parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.query(query, [req.body.email])
// BAD: XSS
;<div dangerouslySetInnerHTML={{ __html: userInput }} />
// GOOD: Escape user input
import DOMPurify from 'dompurify'
const sanitized = DOMPurify.sanitize(userInput)
;<div dangerouslySetInnerHTML={{ __html: sanitized }} />
A04:不安全的设计
如何检测:
A05:安全配置错误
如何检测:
// BAD: Exposes stack trace
app.use((err, req, res, next) => {
res.status(500).json({ error: err.stack })
})
// GOOD: Generic error message
app.use((err, req, res, next) => {
logger.error(err)
res.status(500).json({ error: 'Internal server error' })
})
A06-A10:其他关键问题
npm audit、Dependabot)GDPR(通用数据保护条例)
实施清单:
HIPAA(健康保险可携性和责任法案)
实施清单:
SOC 2(服务组织控制 2)
实施清单:
PCI-DSS(支付卡行业数据安全标准)
实施清单:
应用: 项目管理 SaaS
资产:
信任边界:
边界 1(用户 ↔ Web 应用)的 STRIDE 分析:
| 威胁 | 风险 | 缓解措施 |
|---|---|---|
| S: 凭证盗窃 | 高 | MFA、密码哈希(bcrypt) |
| T: 会话劫持 | 中 | HttpOnly Cookie、SameSite、CSRF 令牌 |
| R: 否认操作 | 低 | 所有用户操作的审计日志 |
| I: 通过 XSS 数据暴露 | 高 | 内容安全策略、输入清理 |
| D: 暴力登录 | 中 | 速率限制(5 次尝试/分钟) |
| E: 账户接管 | 高 | 电子邮件验证、MFA |
优先缓解措施:
代码审查: 用户身份验证端点
发现:
严重:SQL 注入(A03)
// Current code (VULNERABLE):
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`
// Recommended fix:
const query = 'SELECT * FROM users WHERE email = ? AND password_hash = ?'
const hashedPassword = bcrypt.hashSync(password, user.salt)
db.query(query, [email, hashedPassword])
高:明文密码(A02)
// Current code (VULNERABLE):
db.users.create({ email, password })
// Recommended fix:
const hashedPassword = await bcrypt.hash(password, 10)
db.users.create({ email, password: hashedPassword })
中:无速率限制(A04)
// Recommended fix:
const rateLimit = require('express-rate-limit')
const loginLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 5 // 5 attempts
})
app.post('/login', loginLimiter, loginHandler)
行动: 部署前修复严重和高危问题。发布后添加中危问题。
要求: 实现数据主体权利
实施:
1. 访问权(DSAR)
app.get('/api/user/data-export', authMiddleware, async (req, res) => {
const userId = req.user.id
const userData = {
profile: await db.users.findById(userId),
projects: await db.projects.findByUser(userId),
comments: await db.comments.findByUser(userId),
activity: await db.activityLog.findByUser(userId)
}
res.setHeader('Content-Type', 'application/json')
res.setHeader('Content-Disposition', 'attachment; filename=my-data.json')
res.json(userData)
})
2. 删除权
app.delete('/api/user/account', authMiddleware, async (req, res) => {
const userId = req.user.id
// 匿名化而非删除(为法律合规保留)
await db.users.update(userId, {
email: `deleted-${userId}@example.com`,
name: 'Deleted User',
deleted_at: new Date()
})
// 删除 PII
await db.sessions.deleteByUser(userId)
await db.notifications.deleteByUser(userId)
res.json({ message: 'Account deleted successfully' })
})
3. 同意管理
const user = {
email,
marketing_consent: req.body.marketingConsent || false,
analytics_consent: req.body.analyticsConsent || false,
consent_date: new Date()
}
反模式: 先构建,后安全 结果: 昂贵的返工,生产环境中的漏洞
更好的做法: 从设计阶段集成安全
反模式: 仅在前端验证 结果: 攻击者使用 curl 绕过
更好的做法: 始终在后端验证
反模式: 自定义加密或哈希 结果: 弱加密,漏洞
更好的做法: 使用经过验证的库(bcrypt、libsodium)
反模式: "我们合规,所以我们安全" 结果: 合规但不安全
更好的做法: 合规是最低要求;安全是持续过程
反模式: 只修复严重问题 结果: 积少成多导致失败
更好的做法: 系统性地处理所有严重级别
使用安全架构师时,产出:
威胁模型
安全架构文档
安全代码审查报告
合规性检查清单
安全架构师在以下情况下有效:
记住: 安全不是一项功能,而是基础。从一开始就构建它。
每周安装数
0
仓库
GitHub 星标数
18
首次出现
Jan 1, 1970
安全审计
Security Architect is a consolidated skill that covers the complete security lifecycle: threat modeling, secure design principles, secure coding practices, and regulatory compliance. It ensures security is integrated from the start, not bolted on at the end.
Consolidated from:
Use Security Architect when:
S - Spoofing (Authentication)
T - Tampering (Integrity)
R - Repudiation (Accountability)
I - Information Disclosure (Confidentiality)
D - Denial of Service (Availability)
E - Elevation of Privilege (Authorization)
Step 1: Identify Assets
Step 2: Identify Trust Boundaries
Step 3: Apply STRIDE to Each Boundary For each boundary, ask:
Step 4: Assess Risk
Risk = Likelihood × Impact
Likelihood:
- High (likely to occur)
- Medium (may occur)
- Low (unlikely to occur)
Impact:
- Critical (data breach, financial loss, legal liability)
- High (significant damage, downtime)
- Medium (limited damage, temporary disruption)
- Low (minimal impact)
Risk Level:
- Critical: Immediate action required
- High: Address before launch
- Medium: Address post-launch
- Low: Monitor, may accept risk
Step 5: Define Mitigations For each threat, document:
1. Defense in Depth Multiple layers of security controls. If one fails, others still protect.
Example:
2. Least Privilege Users/systems only have minimum permissions needed.
Example:
3. Zero Trust Never trust, always verify. Even internal networks are untrusted.
Example:
4. Secure by Default Default configuration is secure. Users must opt-in to less secure options.
Example:
5. Fail Securely When errors occur, fail in a way that doesn't compromise security.
Example:
Authentication:
Authorization:
@requireRole('admin')Data Protection:
API Security:
Secrets Management:
A01: Broken Access Control
/user/123 → /user/456How to Detect:
// BAD: No authorization check
app.get('/api/users/:id', (req, res) => {
const user = db.users.findById(req.params.id)
res.json(user) // Anyone can see any user!
})
// GOOD: Check ownership
app.get('/api/users/:id', authMiddleware, (req, res) => {
const requestedId = req.params.id
const currentUserId = req.user.id
if (requestedId !== currentUserId && !req.user.isAdmin) {
return res.status(403).json({ error: 'Forbidden' })
}
const user = db.users.findById(requestedId)
res.json(user)
})
A02: Cryptographic Failures
How to Detect:
// BAD: Plaintext password
const user = { email, password: req.body.password }
db.users.create(user)
// GOOD: Hash with bcrypt
const bcrypt = require('bcrypt')
const hashedPassword = await bcrypt.hash(req.body.password, 10)
const user = { email, password: hashedPassword }
db.users.create(user)
A03: Injection
How to Detect:
// BAD: SQL Injection
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`
db.query(query) // Attacker can send: ' OR '1'='1
// GOOD: Parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.query(query, [req.body.email])
// BAD: XSS
;<div dangerouslySetInnerHTML={{ __html: userInput }} />
// GOOD: Escape user input
import DOMPurify from 'dompurify'
const sanitized = DOMPurify.sanitize(userInput)
;<div dangerouslySetInnerHTML={{ __html: sanitized }} />
A04: Insecure Design
How to Detect:
A05: Security Misconfiguration
How to Detect:
// BAD: Exposes stack trace
app.use((err, req, res, next) => {
res.status(500).json({ error: err.stack })
})
// GOOD: Generic error message
app.use((err, req, res, next) => {
logger.error(err)
res.status(500).json({ error: 'Internal server error' })
})
A06-A10: Other Critical Issues
npm audit, Dependabot)GDPR (General Data Protection Regulation)
Implementation Checklist:
HIPAA (Health Insurance Portability and Accountability Act)
Implementation Checklist:
SOC 2 (Service Organization Control 2)
Implementation Checklist:
PCI-DSS (Payment Card Industry Data Security Standard)
Implementation Checklist:
Application: Project Management SaaS
Assets:
Trust Boundaries:
STRIDE Analysis for Boundary 1 (User ↔ Web App):
| Threat | Risk | Mitigation |
|---|---|---|
| S: Credential theft | High | MFA, password hashing (bcrypt) |
| T: Session hijacking | Medium | HttpOnly cookies, SameSite, CSRF tokens |
| R: Denied action | Low | Audit logs for all user actions |
| I: Data exposure via XSS | High | Content Security Policy, input sanitization |
| D: Brute force login | Medium | Rate limiting (5 attempts/min) |
| E: Account takeover | High | Email verification, MFA |
Priority Mitigations:
Code Review: User authentication endpoint
Findings:
CRITICAL: SQL Injection (A03)
// Current code (VULNERABLE):
const query = `SELECT * FROM users WHERE email = '${email}' AND password = '${password}'`
// Recommended fix:
const query = 'SELECT * FROM users WHERE email = ? AND password_hash = ?'
const hashedPassword = bcrypt.hashSync(password, user.salt)
db.query(query, [email, hashedPassword])
HIGH: Plaintext Passwords (A02)
// Current code (VULNERABLE):
db.users.create({ email, password })
// Recommended fix:
const hashedPassword = await bcrypt.hash(password, 10)
db.users.create({ email, password: hashedPassword })
MEDIUM: No Rate Limiting (A04)
// Recommended fix:
const rateLimit = require('express-rate-limit')
const loginLimiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 5 // 5 attempts
})
app.post('/login', loginLimiter, loginHandler)
Action: Fix CRITICAL and HIGH before deployment. Add MEDIUM post-launch.
Requirement: Implement data subject rights
Implementation:
1. Right to Access (DSAR)
app.get('/api/user/data-export', authMiddleware, async (req, res) => {
const userId = req.user.id
const userData = {
profile: await db.users.findById(userId),
projects: await db.projects.findByUser(userId),
comments: await db.comments.findByUser(userId),
activity: await db.activityLog.findByUser(userId)
}
res.setHeader('Content-Type', 'application/json')
res.setHeader('Content-Disposition', 'attachment; filename=my-data.json')
res.json(userData)
})
2. Right to Erasure
app.delete('/api/user/account', authMiddleware, async (req, res) => {
const userId = req.user.id
// Anonymize instead of delete (retain for legal compliance)
await db.users.update(userId, {
email: `deleted-${userId}@example.com`,
name: 'Deleted User',
deleted_at: new Date()
})
// Delete PII
await db.sessions.deleteByUser(userId)
await db.notifications.deleteByUser(userId)
res.json({ message: 'Account deleted successfully' })
})
3. Consent Management
const user = {
email,
marketing_consent: req.body.marketingConsent || false,
analytics_consent: req.body.analyticsConsent || false,
consent_date: new Date()
}
Antipattern: Build first, secure later Result: Expensive retrofitting, vulnerabilities in production
Better: Integrate security from design phase
Antipattern: Only validate on frontend Result: Attacker bypasses with curl
Better: Always validate on backend
Antipattern: Custom encryption or hashing Result: Weak crypto, vulnerabilities
Better: Use proven libraries (bcrypt, libsodium)
Antipattern: "We're compliant, so we're secure" Result: Compliant but insecure
Better: Compliance is minimum; security is ongoing
Antipattern: Only fix CRITICAL issues Result: Death by a thousand cuts
Better: Systematically address all severity levels
When using Security Architect, produce:
Threat Model
Security Architecture Document
Secure Code Review Report
Compliance Checklist
Security Architect is effective when:
Remember: Security is not a feature, it's a foundation. Build it in from the start.
Weekly Installs
0
Repository
GitHub Stars
18
First Seen
Jan 1, 1970
Security Audits
Better Auth 最佳实践指南:集成、配置与安全设置完整教程
30,700 周安装