vulnerability-scanner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Vulnerability Scanner

漏洞扫描器

Think like an attacker, defend like an expert. 2025 threat landscape awareness.

像攻击者一样思考，像专家一样防御。洞悉2025年威胁态势。

🔧 Runtime Scripts

🔧 运行时脚本

Execute for automated validation:

Script	Purpose	Usage
`scripts/security_scan.py`	Validate security principles applied	`python scripts/security_scan.py <project_path>`

执行以实现自动化验证：

脚本	用途	使用方法
`scripts/security_scan.py`	验证已应用的安全原则	`python scripts/security_scan.py <project_path>`

📋 Reference Files

📋 参考文件

File	Purpose
checklists.md	OWASP Top 10, Auth, API, Data protection checklists

文件	用途
checklists.md	OWASP Top 10、身份验证、API、数据保护检查清单

1. Security Expert Mindset

1. 安全专家思维模式

Core Principles

核心原则

Principle	Application
Assume Breach	Design as if attacker already inside
Zero Trust	Never trust, always verify
Defense in Depth	Multiple layers, no single point
Least Privilege	Minimum required access only
Fail Secure	On error, deny access

原则	应用场景
Assume Breach（假设已遭入侵）	按攻击者已进入系统的前提进行设计
Zero Trust（零信任）	永不信任，始终验证
Defense in Depth（纵深防御）	多层防护，无单点故障
Least Privilege（最小权限）	仅授予所需的最小访问权限
Fail Secure（安全失败）	出错时拒绝访问

Threat Modeling Questions

威胁建模问题

Before scanning, ask:

What are we protecting? (Assets)
Who would attack? (Threat actors)
How would they attack? (Attack vectors)
What's the impact? (Business risk)

扫描前，请思考：

我们要保护什么？（资产）
谁会发起攻击？（威胁行为者）
他们会如何攻击？（攻击向量）
影响是什么？（业务风险）

2. OWASP Top 10:2025

Risk Categories

风险类别

Rank	Category	Think About
A01	Broken Access Control	Who can access what? IDOR, SSRF
A02	Security Misconfiguration	Defaults, headers, exposed services
A03	Software Supply Chain 🆕	Dependencies, CI/CD, build integrity
A04	Cryptographic Failures	Weak crypto, exposed secrets
A05	Injection	User input → system commands
A06	Insecure Design	Flawed architecture
A07	Authentication Failures	Session, credential management
A08	Integrity Failures	Unsigned updates, tampered data
A09	Logging & Alerting	Blind spots, no monitoring
A10	Exceptional Conditions 🆕	Error handling, fail-open states

排名	类别	思考要点
A01	Broken Access Control（访问控制失效）	谁可以访问什么？IDOR、SSRF
A02	Security Misconfiguration（安全配置错误）	默认配置、请求头、暴露的服务
A03	Software Supply Chain 🆕（软件供应链）	依赖项、CI/CD、构建完整性
A04	Cryptographic Failures（密码学失败）	弱加密、暴露的密钥
A05	Injection（注入攻击）	用户输入→系统命令
A06	Insecure Design（不安全设计）	存在缺陷的架构
A07	Authentication Failures（身份验证失败）	会话、凭证管理
A08	Integrity Failures（完整性失败）	未签名的更新、被篡改的数据
A09	Logging & Alerting（日志与告警）	监控盲区、无监控机制
A10	Exceptional Conditions 🆕（异常情况）	错误处理、故障开放状态

2025 Key Changes

2025年关键变化

2021 → 2025 Shifts:
├── SSRF merged into A01 (Access Control)
├── A02 elevated (Cloud/Container configs)
├── A03 NEW: Supply Chain (major focus)
├── A10 NEW: Exceptional Conditions
└── Focus shift: Root causes > Symptoms

2021 → 2025 变化：
├── SSRF 并入 A01（访问控制）
├── A02 优先级提升（云/容器配置）
├── A03 新增：供应链（重点关注）
├── A10 新增：异常情况
└── 重心转移：根源 > 症状

3. Supply Chain Security (A03)

3. 供应链安全（A03）

Attack Surface

攻击面

Vector	Risk	Question to Ask
Dependencies	Malicious packages	Do we audit new deps?
Lock files	Integrity attacks	Are they committed?
Build pipeline	CI/CD compromise	Who can modify?
Registry	Typosquatting	Verified sources?

向量	风险	思考问题
依赖项	恶意包	我们是否审核新依赖？
锁定文件	完整性攻击	是否已提交锁定文件？
构建流水线	CI/CD 被攻陷	谁可以修改流水线？
注册表	仿冒包攻击	是否使用已验证的源？

Defense Principles

防御原则

Verify package integrity (checksums)
Pin versions, audit updates
Use private registries for critical deps
Sign and verify artifacts

验证包完整性（校验和）
固定版本，审核更新
对关键依赖使用私有注册表
签名并验证制品

4. Attack Surface Mapping

4. 攻击面映射

What to Map

映射内容

Category	Elements
Entry Points	APIs, forms, file uploads
Data Flows	Input → Process → Output
Trust Boundaries	Where auth/authz checked
Assets	Secrets, PII, business data

类别	元素
入口点	API、表单、文件上传
数据流	输入 → 处理 → 输出
信任边界	进行身份验证/授权的位置
资产	密钥、PII、业务数据

Prioritization Matrix

优先级矩阵

Risk = Likelihood × Impact

High Impact + High Likelihood → CRITICAL
High Impact + Low Likelihood  → HIGH
Low Impact + High Likelihood  → MEDIUM
Low Impact + Low Likelihood   → LOW

风险 = 可能性 × 影响

高影响 + 高可能性 → 严重（CRITICAL）
高影响 + 低可能性  → 高（HIGH）
低影响 + 高可能性  → 中（MEDIUM）
低影响 + 低可能性   → 低（LOW）

5. Risk Prioritization

5. 风险优先级排序

CVSS + Context

CVSS + 上下文

Factor	Weight	Question
CVSS Score	Base severity	How severe is the vuln?
EPSS Score	Exploit likelihood	Is it being exploited?
Asset Value	Business context	What's at risk?
Exposure	Attack surface	Internet-facing?

因素	权重	思考问题
CVSS 评分	基础严重程度	漏洞的严重程度如何？
EPSS 评分	被利用的可能性	该漏洞是否正在被利用？
资产价值	业务上下文	面临风险的是什么？
暴露程度	攻击面	是否面向互联网？

Prioritization Decision Tree

优先级决策树

Is it actively exploited (EPSS >0.5)?
├── YES → CRITICAL: Immediate action
└── NO → Check CVSS
         ├── CVSS ≥9.0 → HIGH
         ├── CVSS 7.0-8.9 → Consider asset value
         └── CVSS <7.0 → Schedule for later

是否正在被主动利用（EPSS >0.5）？
├── 是 → 严重（CRITICAL）：立即处理
└── 否 → 检查 CVSS
         ├── CVSS ≥9.0 → 高（HIGH）
         ├── CVSS 7.0-8.9 → 结合资产价值判断
         └── CVSS <7.0 → 安排后续处理

6. Exceptional Conditions (A10 - New)

6. 异常情况（A10 - 新增）

Fail-Open vs Fail-Closed

故障开放 vs 故障关闭

Scenario	Fail-Open (BAD)	Fail-Closed (GOOD)
Auth error	Allow access	Deny access
Parsing fails	Accept input	Reject input
Timeout	Retry forever	Limit + abort

场景	故障开放（不良）	故障关闭（良好）
身份验证错误	允许访问	拒绝访问
解析失败	接受输入	拒绝输入
超时	无限重试	限制重试次数并终止

What to Check

检查要点

Exception handlers that catch-all and ignore
Missing error handling on security operations
Race conditions in auth/authz
Resource exhaustion scenarios

捕获所有异常并忽略的异常处理器
安全操作缺失错误处理
身份验证/授权中的竞争条件
资源耗尽场景

7. Scanning Methodology

7. 扫描方法论

Phase-Based Approach

分阶段方法

1. RECONNAISSANCE
   └── Understand the target
       ├── Technology stack
       ├── Entry points
       └── Data flows

2. DISCOVERY
   └── Identify potential issues
       ├── Configuration review
       ├── Dependency analysis
       └── Code pattern search

3. ANALYSIS
   └── Validate and prioritize
       ├── False positive elimination
       ├── Risk scoring
       └── Attack chain mapping

4. REPORTING
   └── Actionable findings
       ├── Clear reproduction steps
       ├── Business impact
       └── Remediation guidance

1. RECONNAISSANCE（侦察）
   └── 了解目标
       ├── 技术栈
       ├── 入口点
       └── 数据流

2. DISCOVERY（发现）
   └── 识别潜在问题
       ├── 配置审查
       ├── 依赖分析
       └── 代码模式搜索

3. ANALYSIS（分析）
   └── 验证并排序优先级
       ├── 排除误报
       ├── 风险评分
       └── 攻击链映射

4. REPORTING（报告）
   └── 可执行的发现结果
       ├── 清晰的复现步骤
       ├── 业务影响
       └── 修复指导

8. Code Pattern Analysis

8. 代码模式分析

High-Risk Patterns

高风险模式

Pattern	Risk	Look For
String concat in queries	Injection	`"SELECT * FROM " + user_input`
Dynamic code execution	RCE	`eval()` , `exec()` , `Function()`
Unsafe deserialization	RCE	`pickle.loads()` , `unserialize()`
Path manipulation	Traversal	User input in file paths
Disabled security	Various	`verify=False` , `--insecure`

模式	风险	检查要点
查询中的字符串拼接	注入攻击	`"SELECT * FROM " + user_input`
动态代码执行	远程代码执行（RCE）	`eval()` , `exec()` , `Function()`
不安全的反序列化	远程代码执行（RCE）	`pickle.loads()` , `unserialize()`
路径操作	路径遍历	文件路径中包含用户输入
禁用安全机制	各类风险	`verify=False` , `--insecure`

Secret Patterns

密钥模式

Type	Indicators
API Keys	`api_key` , `apikey` , high entropy
Tokens	`token` , `bearer` , `jwt`
Credentials	`password` , `secret` , `key`
Cloud	`AWS_` , `AZURE_` , `GCP_` prefixes

类型	标识
API 密钥	`api_key` , `apikey` , 高熵值
令牌	`token` , `bearer` , `jwt`
凭证	`password` , `secret` , `key`
云服务	`AWS_` , `AZURE_` , `GCP_` 前缀

9. Cloud Security Considerations

9. 云安全注意事项

Shared Responsibility

共享责任模型

Layer	You Own	Provider Owns
Data	✅	❌
Application	✅	❌
OS/Runtime	Depends	Depends
Infrastructure	❌	✅

层级	您负责	服务商负责
数据	✅	❌
应用	✅	❌
操作系统/运行时	视情况而定	视情况而定
基础设施	❌	✅

Cloud-Specific Checks

云专属检查项

IAM: Least privilege applied?
Storage: Public buckets?
Network: Security groups tightened?
Secrets: Using secrets manager?

IAM：是否应用了最小权限原则？
存储：是否存在公共存储桶？
网络：安全组是否已收紧？
密钥：是否使用密钥管理器？

10. Anti-Patterns

10. 反模式

❌ Don't	✅ Do
Scan without understanding	Map attack surface first
Alert on every CVE	Prioritize by exploitability + asset
Ignore false positives	Maintain verified baseline
Fix symptoms only	Address root causes
Scan once before deploy	Continuous scanning
Trust third-party deps blindly	Verify integrity, audit code

❌ 不要做	✅ 应该做
未理解目标就扫描	先映射攻击面
对每个CVE都发出告警	按可利用性+资产价值排序优先级
忽略误报	维护已验证的基线
仅修复症状	解决根源问题
仅在部署前扫描一次	持续扫描
盲目信任第三方依赖	验证完整性，审核代码

11. Reporting Principles

11. 报告原则

Finding Structure

发现结果结构

Each finding should answer:

What? - Clear vulnerability description
Where? - Exact location (file, line, endpoint)
Why? - Root cause explanation
Impact? - Business consequence
How to fix? - Specific remediation

每个发现结果应回答：

是什么？ - 清晰的漏洞描述
在哪里？ - 精确位置（文件、行号、端点）
为什么？ - 根源解释
影响？ - 业务后果
如何修复？ - 具体的修复建议

Severity Classification

严重程度分类

Severity	Criteria
Critical	RCE, auth bypass, mass data exposure
High	Data exposure, privilege escalation
Medium	Limited scope, requires conditions
Low	Informational, best practice

Remember: Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"

严重程度	判定标准
严重（CRITICAL）	远程代码执行（RCE）、身份验证绕过、大规模数据泄露
高（HIGH）	数据泄露、权限提升
中（MEDIUM）	范围有限，需特定条件触发
低（LOW）	信息性内容，最佳实践建议

注意： 漏洞扫描用于发现问题。专家思维用于确定哪些问题至关重要。始终要问：“攻击者会利用这个漏洞做什么？”