如何在Python中使用pytest检测代码中的硬编码密码或密钥？

很多刚接触 pytest 的同学会问：pytest 能自动检测代码里的硬编码密码吗？答案是否定的——pytest 本身是测试框架，不是静态分析工具。它不会主动扫描字符串或变量内容来识别 PASSWORD、API_KEY 这类敏感词。那怎么办？需要通过自定义测试、AST 解析或集成 detect-secrets 等工具来实现主动检查。

为什么 pytest 本身不检测硬编码密码

pytest 是测试运行框架，不是静态代码分析工具。它不会主动扫描字符串或变量内容来识别 PASSWORD、API_KEY 这类敏感词——除非你写测试去显式检查。直接跑 pytest 命令，哪怕代码里明文写了 "sk_live_abc123"，也不会报错或警告。根本原因在于，pytest 的职责是执行测试用例并收集结果，而不是审计源码。如果你希望它检测硬编码密钥，就必须主动告诉它：去哪些文件里查，用什么样的模式匹配，哪些值可以放行。

用 pytest 写测试来主动检查硬编码密钥

核心思路其实很简单：在测试中遍历源码文件，用正则匹配常见密钥模式（比如 r"sk_live_[a-zA-Z0-9]{20,}"），再排除白名单。这种方法适合已有少量配置文件或模块需快速筛查的场景，不需要额外引入复杂的工具链。

• 把扫描逻辑封装成一个 fixture，比如 check_no_hardcoded_secrets，在每个测试模块开头调用。这样既统一入口，又方便复用。
• 匹配关键词时要区分上下文：字符串字面量要查，但注释、测试数据、mock 值应加入白名单避免误报——否则一个假的 "test_key_123" 也能让测试红一片。
• 推荐用 ast 模块解析语法树而非简单 grep，因为 grep 遇上 "sk_" + "live_" + "abc" 这种拼接写法就会直接漏掉，而 AST 能识别真正的字符串字面量。
• 示例片段：

def test_no_hardcoded_keys(check_no_hardcoded_secrets):
    check_no_hardcoded_secrets("myapp/utils.py")

更靠谱的做法：用 pre-commit + detect-secrets 配合 pytest

必须说一句：硬编码密钥属于代码质量/安全问题，应该在提交前拦截，而不是等测试阶段才发现。pytest 只适合做兜底或专项验证，指望它当主力防线不太现实。

• 安装 detect-secrets：pip install detect-secrets
• 初始化配置：detect-secrets scan --baseline .secrets.baseline
• 加到 .pre-commit-config.yaml 中，每次 git commit 自动扫描，能在代码入库前就把问题卡住。
• 若必须集成进 pytest 流程，可用 subprocess.run(["detect-secrets", "scan"], capture_output=True) 调用，但需要注意 baseline 文件路径和退出码处理——别因为子进程报错导致整个测试套件崩掉。

常见误报和绕过陷阱

正则匹配看起来简单，但实际用起来坑不少。变形写法很容易漏测，比如 "sk_live_" + os.getenv("KEY_SUFFIX") 这种动态拼接，正则根本抓不到。而另一边，像 "test_key_123" 这种无害字符串又可能被误判为密钥，搞得全是误报。

• 避免只搜 "password" 这种泛关键词，优先匹配密钥格式（如 Stripe、AWS、GitHub 的固定前缀+长度），这样准确率高得多。
• 环境变量读取必须用 os.getenv("DB_PASSWORD")，不能用 os.environ["DB_PASSWORD"] —— 后者在 key 不存在时直接抛 KeyError，导致测试崩溃而非安全问题暴露，这个细节很多人不注意。
• pytest 的 monkeypatch 可以临时替换 os.getenv 返回空值，借此验证代码是否真依赖环境变量而非 fallback 到硬编码。这是测试层面的一个小技巧，能帮你揪出那些“假装用环境变量，实际兜底写死”的代码。

说到底，硬编码密钥检测是工程流程问题，不是单靠 pytest 就能解决的。真正有效的防线在 pre-commit、CI 扫描，以及开发时对 os.getenv 和 configparser 的强制使用习惯。pytest 在这里只是最后一道人工可触发的验证环节，别指望它自动发现所有 case。