bandit可快速检测硬编码密钥（如b108）和危险函数调用（如b102、b112），需启用-ll -iii参数并聚焦特定规则编号，避免误漏；pip-audit用于识别依赖cve，应优先尝试自动修复，对不可升级项须白名单+注释说明；ci中应仅扫描变更代码、限定cve范围，并将结果交人工研判；静态扫描无法覆盖运行时风险（如oom、慢速攻击），须结合运行时防护与waf联动测试。
怎么用 bandit 快速扫出硬编码密钥和危险函数调用
发布前最该盯住的是“人肉埋雷”——比如把 os.system() 直接拼接用户输入，或者在代码里写死 API_KEY = "sk-xxx"。这些 bandit 能直接标出来，但默认配置太松，容易漏。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 装完立刻跑
bandit -r . -ll -iii：-r递归扫描，-ll开启低危告警（比如硬编码密码），-iii把 info 级别也打出来（否则默认只报中高危） - 重点看
B102（exec）、B108（硬编码路径）、B112（使用eval）、B501（urllib2.urlopen不校验证书）这类编号，它们对应具体漏洞模式 - 别信
--skip随意跳过规则——比如跳掉B101（assert 用于生产逻辑），可能掩盖权限绕过风险
pip-audit 扫依赖时为什么总报一堆“已知漏洞”却没法修
它报的不是你的代码问题，是第三方包的 setup.py 或 pyproject.toml 里声明的依赖版本有 CVE。但很多提示的“升级到 X.Y.Z”根本不可行——上游包没发新版，或你用的框架锁死了子依赖。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先跑
pip-audit -r requirements.txt --fix，自动尝试升到安全小版本；失败时看输出里哪一行卡住，比如django 和 <code>djangorestframework>=3.14冲突，就得手动协调 - 对无法升级的包，用
pip-audit --ignore CVE-2023-12345加白名单，但必须同步在代码注释里写清原因和缓解措施（比如“已用django.middleware.security.SecurityMiddleware拦截 xss”） - 注意
pip-audit不扫git+https或本地路径依赖，这类得单独检查pyproject.toml里的git提交哈希是否在已知漏洞范围内
CI 里加扫描但 PR 总被拦住：如何让 bandit 和 pip-audit 只报真正要处理的问题
CI 里一开就红，不是工具不行，是默认把“所有历史问题”都当错误。结果团队要么关掉，要么每天花时间修十年前的 print 日志泄露。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
bandit -r . -f json -o bandit-report.json生成 JSON，再用脚本过滤出line_number在本次 git diff 范围内的条目——只扫改动行及其上下 3 行 -
pip-audit加--vulnerability-id参数限定只查特定 CVE，配合 github Security Advisories 的 webhook 自动拉取当前仓库实际受影响的漏洞列表 - 别把扫描结果直接设为 CI 失败项，改用
exit 0并把报告存成 artifact，靠人工 review + comment 自动标记高危项——机器负责发现，人负责判断上下文
为什么扫描通过了，上线后还是被 WAF 拦？
静态扫描管不到运行时行为。比如 bandit 看不出你用 json.loads() 解析用户传的超大字符串导致 OOM，pip-audit 也发现不了你用 requests.get(url, timeout=30) 让攻击者发起慢速 HTTP 攻击。
实操建议：
立即学习“Python免费学习笔记（深入）”；