python safety
说Python Bandit之前，先聊聊安全检测这件事儿。平时写代码，很多人第一反应是性能和可读性，安全问题常常是最后才想起来的东西。打个比方，就像装修房子，大家忙着选地板颜色、挑沙发样式，很少有人会在动工前就把防火报警器的位置都规划好。但问题是，等到房子装好了再装报警器，线路就得走明线，难看不说，还容易出问题。Python代码的安全隐患也是这个道理——等到代码都跑在生产环境上了，才发现有SQL注入或者硬编码密钥的问题，那代价就大了。
Bandit就是专门干这个事的工具。它不是那种运行时检测的防护系统，而是像给代码做“体检”一样，静态地扫描源代码。什么意思呢？就是它不需要真正运行你的程序，只需要读你的代码文件，就能找出潜在的安全风险点。这种设计思路很实际——大部分安全问题其实都出在代码的写法上，比如用了不安全的函数、没有做输入校验、把敏感信息写死在代码里。这些东西，只要你写了，就能被静态分析出来。
它能做的事情还挺细致的。举个例子，你写了一个用subprocess调用系统命令的模块，Bandit会提醒你这个调用是不是拼接了用户输入。哪怕只是os.system('ls ' + filename)这样的写法，它也能嗅到危险的味道。再比如你在代码里用了eval或者exec，或者pickle.load从不可信来源加载数据，这些在Bandit看来都属于高风险操作。它甚至会检查你有没有在requests库的调用里设了verify=False禁用SSL证书验证，或者用了默认的密钥、硬编码的密码等等。这些东西有时候真的很容易被忽略——尤其是刚开始写代码的时候，为了省事直接关了验证，后来就忘了改回来。
使用起来也很简单。安装只需要pip install bandit，然后直接在项目根目录下跑bandit -r .，它会递归扫描所有Python文件。默认的输出格式是文本，会列出每个问题的严重等级（HIGH、MEDIUM、LOW）和具体位置。如果觉得输出太冗长，可以用-f json输出成JSON格式，方便集成到其他工具链。还有一个很贴心的选项是--skip，可以跳过某些规则。比如你有一个模块里面不可避免地用了assert（在某些场景下assert可能被当作安全隐患，因为它可能在优化模式下被跳过），但你确认那个模块的逻辑没问题，就可以通过--skip B101跳过那个规则（B101是assert的检测编号）。不过，跳过规则的时候最好在项目文档里说明原因，不然以后换个人维护代码，看到跳过了安全检查，心里难免犯嘀咕。
说到最佳实践，有一些小经验可以分享。首先，Bandit应该集成到CI/CD流水线里，而不是只在本地跑一跑。道理很简单，本地跑完忘记修是常有的事，但如果PR合并之前CI就拒绝了，那就逼着团队必须处理。通常的做法是在pyproject.toml或者.bandit文件里配置白名单规则和严重度阈值，比如只把HIGH级别的当作阻断，MEDIUM和LOW的允许通过但记录成警告。其次，Bandit的基线文件（baseline）很有用。如果项目是半路开始使用Bandit，一开始肯定会跑出一大堆问题，这时候不要一股脑全修完（时间不允许），可以先生成一个基线文件bandit-baseline.json，然后让后续的扫描只报告增量问题。这样团队可以慢慢地、有条理地修复老问题，同时新代码绝不带新问题进来。还有一个细节值得一提：Bandit对动态代码生成和异步编程的支持有限。比如用了exec动态拼接代码，或者大量使用asyncio的高级特性，它的静态分析可能会漏报。这时候就需要结合代码审查来做补充，不能完全依赖工具。
同类工具里，比较常见的有Safety、Semgrep和Sourcery。Safety专注在检查Python依赖包的已知漏洞，比如某个版本的requests有CVE，它会提醒你升级。这和Bandit的定位完全不同——Bandit看的是你写的代码，Safety看的是你用的外部包。Semgrep更像一个通用静态分析框架，规则可定制性极强，你需要什么规则可以自己写，但同样学习成本和配置成本也高很多。如果要类比，Bandit像是便利店，开箱即用，常见问题都能覆盖；Semgrep像是超市，什么都有，但需要你自己推着购物车去挑选。Sourcery则偏向代码质量和可维护性，比如建议你减少循环嵌套、提取公共代码，安全检测只是它功能的一小部分。所以在实际项目中，这些工具通常搭配使用：Bandit管代码安全，Safety管依赖安全，Semgrep处理复杂的自定义规则（比如检测敏感信息泄露的特定模式），形成一道多层的防线。
总的来说，Bandit不是什么高大上的东西，它就是一个老老实实的静态安全扫描工具。它的价值不在于能发现多高深的漏洞——事实上，SQL注# # Python Safety：一个被低估的依赖安全检查工具
说实话，刚开始接触Python Safety的时候，我有点不以为然。想着不就是又一个安全检查工具嘛，市面上那么多，有什么特别的？直到有次线上事故，一个不起眼的第三方库版本带了严重漏洞，我才真正重视起这个工具。
它到底是什么
Python Safety，简单说就是个扫描Python依赖包已知安全漏洞的命令行工具。它背后连着Safety DB这个数据库——专门收集Python包安全漏洞信息的开放数据库。不像有些工具需要你注册账号、配置密钥，Safety开箱即用，安装完直接跑就行。
它更像是个“对照清单”。把当前项目里装的所有Python包和版本号提取出来，跟数据库里的漏洞列表逐一比对。如果某个包版本恰好落在有漏洞的范围里，就提醒你。原理不复杂，但胜在直接有效。
它能做什么
最核心的能力就一个：告诉你哪些依赖包有安全隐患。但这里面有几个细节值得说：
第一，它只关注已知漏洞。那些还没被公开、没收入数据库的安全问题，它无能为力。这就像天气预报只能预报气象站观测到的数据一样。
第二，它能区分直接依赖和间接依赖。比如你的项目装了个requests库，requests依赖了urllib3。如果urllib3有漏洞，Safety会告诉你，这个漏洞是通过什么路径引入的。这点在实际排查时特别有用——不会让你在几十个依赖里大海捞针。
第三，它能生成不同格式的报告。命令行直接输出、JSON格式、表格格式，方便集成到CI/CD流水线或者发到监控系统。我一般让CI跑完测试后自动跑一遍Safety，生成JSON报告存档。
有个小坑要注意：Safety默认检查的是当前激活的Python环境里的包。如果你用虚拟环境（强烈建议用），记得先激活虚拟环境再跑，不然检查的就是全局Python环境了。
怎么使用
安装特别简单：
pipinstallsafety基础用法：
safety check这会在当前Python环境里扫描所有安装的包。如果要扫描特定项目的requirements.txt文件：
safety check-rrequirements.txt如果扫描完没发现漏洞，退出码是0，有漏洞则返回非0。这个特性很适合集成到CI：
# 如果发现漏洞，构建失败safety check||exit1有个参数--full-report可以显示更详细的信息，包括每个漏洞的描述、影响版本范围、修复建议。排查问题时很有帮助。
Safety还会生成一个安全报告，里面包含找到多少个漏洞、每个漏洞的严重程度（CRITICAL、HIGH、MEDIUM、LOW）。别只看数量，严重程度才是重点。有时一个CRITICAL级别的漏洞比十个LOW级别的更紧迫。
最佳实践
这些年用下来，有几个做法比较推荐：
定时扫描比一次性扫描更重要。漏洞是动态的，新的CVE（通用漏洞披露）不断出现。今天安全的应用，下个月可能就发现漏洞。建议至少每周跑一次全量扫描，或者每次更新依赖后立即扫描。
别用最新版，用经过验证的版本。很多人觉得最新版本最安全，其实不一定。有时补丁本身会引入新问题。我一般等一个版本发布两周左右，看社区反馈稳定后再升级。
结合依赖锁文件使用。像pip freeze生成的requirements.txt或者Poetry的poetry.lock，这些锁文件记录了精确的版本号。用Safety扫描锁文件比扫描当前环境更准确，因为锁文件不会受其他项目影响。
设置白名单机制。有些已知漏洞不影响你的使用场景（比如某些漏洞只影响某个特定操作系统版本），可以设置忽略规则，避免每次扫描都报同样的假阳性。但白名单要谨慎添加，并定期审查。
和同类技术对比
几个常见的替代方案：
Bandit：主要扫描Python代码本身的安全问题，比如SQL注入、命令注入、硬编码密码等。Safety专注于依赖包，Bandit关注代码质量，两者互补。最好两个都用，从不同维度保证安全。
Snyk：功能比Safety强大得多，不仅检查Python依赖，还覆盖容器镜像、基础设施即代码等多种类型。但背后是商业公司，免费版有扫描次数限制。对于小团队或个人项目，Safety的开源属性更有吸引力。
GitHub Dependabot：集成在GitHub里，自动提PR更新有漏洞的依赖。但依赖GitHub平台，如果你用的不是GitHub，或者项目在私有仓库，配置起来相对繁琐。Safety可以脱离平台独立使用，灵活性更高。
OWASP Dependency-Check：Java出身，后来支持了Python。但它是以Java工具的思路去设计的，对Python生态的理解不如Safety深入。比如虚环境管理、pip的特性适配等方面，Safety做得更自然。
总的来说，Safety的定位很清晰：轻量、专注、易用。不试图包揽一切，只在依赖安全检查这个点上做到位。对大多数Python项目来说，这就够了。
如果项目对安全性要求特别高，可以考虑用Safety做基础安全检查，再配合Snyk或Dependabot做更全面的防线。但别贪心搞一堆工具结果互相冲突——安全和很多事一样，过犹不及。入、命令注入这些经典问题，更多的依赖开发者本身的意识——而在于它能帮你守住一些基础底线。就像开车出门前系安全带，大多数人可能一辈子用不上，但你知道它在那儿，心里就踏实。如果你还没试过，可以去翻翻自己项目的代码，跑一遍Bandit看看，说不定会发现某个角落里躺着一个早就该改掉的小隐患。