bandit可快速检测硬编码密钥（如b108）和危险函数调用（如b102、b112），需启用-ll -iii参数并聚焦特定规则编号，避免误漏；pip-audit用于识别依赖cve，应优先尝试自动修复，对不可升级项须白名单+注释说明；ci中应仅扫描变更代码、限定cve范围，并将结果交人工研判；静态扫描无法覆盖运行时风险（如oom、慢速攻击），须结合运行时防护与waf联动测试。
怎么用 bandit 快速扫出硬编码密钥和危险函数调用
发布前最该盯住的是“人肉埋雷”——比如把 os.system() 直接拼接用户输入，或者在代码里写死 API_KEY = "sk-xxx"。这些 bandit 能直接标出来，但默认配置太松，容易漏。
实操建议：
立即学习“Python免费学习笔记（深入）”；
SLStuan手拉手团购程序(仿拉手网)
下载
手拉手团购系统是一套Groupon模式的开源团购程序，是骏商网络(dream3.cn)旗下开发的一套仿拉手网团购程序，是国内首套采用ASP+MSSQL开发的团购程序，安装超简，功能超全面，在保留手拉手团购系统版权的前提下，允许所有用户永久免费使用、永久免费升级。手拉手团购系统内置多种主流在线支付接口，所有网银用户均可无障碍支付；短信发送团购券和实物团购快递发货等。 SLStuan手拉手团购程序 v
- 装完立刻跑
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免费学习笔记（深入）”；
- 在关键入口加运行时检测：比如用
limits包限制 JSON 解析大小，用timeout参数强制短超时，而不是只靠静态扫描“没报错”就认为安全 - WAF 规则往往基于流量特征（如 SQL 关键字、长 URL、重复 header），扫描工具不会模拟真实请求流。上线前用
curl或httpx发几组边界值请求，观察 WAF 日志里的403原因字段 - 最常被忽略的是日志本身——如果
logging.info("user %s accessed %s", user_id, path)里path来自 request，就可能被注入恶意字符串污染日志系统，这需要结合日志采集器的解析规则一起看
